Modeling sprints Scrum. We solve the problems of interaction with the client and within the team
“The mobile application must be live, the user must see that the project is developing.”
We at Redmadrobot are working on Agile and Scrum agile methodologies. As you know, they imply significant freedom in how project sprints are organized - each company selects a model that is convenient for itself. Cases - information on how teams are organized during the execution of spirits - in external sources is extremely small. We reveal our "kitchen".
To begin with, I will voice the main problems that were highlighted in the production process by the VA. 1. The client wants to see everything at once on the main screen
Often companies think in terms of categories and solutions of the web and want to see all the basic functions, features, services (as if it were the main page of the site) on the launch page of their mobile application. This, to put it mildly, is not always justified, but requires argumentation.
2. The analyst makes up requirements that developers do not like
Developers who read requirements do not. There are analysts who, 10 times during the writing of requirements, discuss them with the developers.
3. Requirements become void at the testing stage.
You need to communicate with testers - they know how to break. It’s useful for the analyst to get a long list of “how it should work” tips before designing.
4. Fantastic design
Layouts must be feasible. Therefore, the requirements for interfaces and design reviews are needed.
5. The application should develop, and it should develop gradually.
It is impossible to implement all the features at once. Therefore, the set of tasks must be limited.
“Improvement is not necessary. Survival is a voluntary matter ”(c) Edward Demming
Sooner or later, any project, even in Agile and Scrum, comes to standardize processes. But perfection is impossible without a close focus on the process itself. It looks like this with us.
The standard sprint at Redmadrobot is 4 weeks. During this time, we manage to go from the formalization of the goal, its implementation in lines of code and rigorous testing to uploading a new version of the application in the App Store and Google Play.
First, we prepare the design requirements, and only then - the development.
Participants:
PM - requests a set of tasks for the future Sprint
RO (Product Owner) from the customer - forms a set of features that are potential candidates for the new
BA sprint - processes information and clarifies open questions
Artifacts:
- a set of tasks for the future sprint in the form feature
- priorities from the customer
Tools: JIRA
The whole procedure is a clarification of the priorities of the previously planned roadmap.
Participants:
BA - fixes requirements, cleans Impact Map of information that is too detailed and is not related to the
RO goal on the part of the customer - is responsible for business goals
UX-designer - helps to think through user goals and methods for achieving them
Artifacts:
- Impact Map
- description of users
- User Stories
- topology of stakeholders
- specification of external systems API
Tools: Xmind, Confluence
All tasks that come to us can be divided into two types :
- there are working API methods
- no methods
It is logical that the development of methods can take a fairly large amount of time. We try not to take such tasks into development, but we can prepare requirements for the development of methods, the interface and work out the design for the future sprint (2 week sprint).
To compile Impact Map you need to answer 4 questions:
At this stage, problem No. 1 is often resolved "Everyone wants to be on the main page."
Participants: DEV, DES, QA, BA, PM, UX-designer.
Artifacts:
- sprint scopes, agreed and approved by the customer.
Tools: Confluence
This is an intermediate checkpoint between the appearance of the specification of requirements and interface requirements. It is determined how much time it will take for the team to complete this task, if there are stop factors that do not allow you to take the task into the sprint, labor costs are estimated. Scope is sent to PM for approval by Product Owner. After that, the sprint is fixed, and adding new features becomes impossible. “The application should develop, and it should develop gradually” - we deal with problem No. 5
Participants: BA, UX designer
Artifacts:
- Use Cases
- content restrictions
- non-functional requirements
Tools: Confluence
In the practice of preparing requirements, we use standard approaches to describe them: Use Cases (template proposed by Alistair Kobern ). Scripts interact well with previously prepared User Stories and cover them. Scenario development is carried out jointly with the UX designer and describes the future behavior of the system, which the designer needs to reflect. Going beyond this framework creates changes in requirements: content restrictions that are identified on the basis of the API specification and communication with the customer, as well as non-functional requirements.
Participants: DEV, DES, QA, BA, PM, UX Designer, PO
Artifacts:
- screen map
Tools: Confluence
As soon as they appear, finished screens are sent to the entire team for review. Checking layouts is carried out according to several indicators:
We continue to solve the problem №4 “Fantastic design”, which we started to deal with at the previous stage
Participants: BA, UX designer
Artifacts:
- Impact Map
- user descriptions
- User Stories
- Use Cases
- non-functional requirements
- content restrictions
- specification of API of external systems
- functional requirements
The objective of this stage is to formally fix the agreements discussed earlier in the form of functional requirements for the developed system. Requirements are born from the interactions of team members and their joint decisions.
It helps:
Participants: DEV, DES, QA, BA, PM, UX designer
Artifacts:
- Impact map
- user descriptions
- User Stories
- Use Cases
- non-functional requirements
- content restrictions
- specification of external systems API
- functional requirements
Tools: Confluence
Tasks at this stage - make sure that the necessary set of requirements for development is fixed, whether they are clear to all team members and are interpreted the same way. When comments and comments appear, the requirements change and go through the re-review procedure, after which they are agreed with the customer.
Participants: BA, DEV, UX-designer
Artifacts:
- sprint scoop agreed by the customer
- specification of API external systems (if available)
Tools: Confluence
The tasks here are divided into two types . In the first case, the API specification is missing - the analyst, together with the development, prepares the specification of requirements for the Backend. It becomes the main one for the future map of screens and is taken into account in content restrictions. In the second case, there is a specification of the API of external systems, but the task is too large to completely go through the entire cycle from analysis to testing. Then the process follows the standard procedure described in the paragraph “Developing Interface Requirements and Design Review”. Then it goes to the next sprint, where it will be covered by the requirements for the mobile application and developed, or put off in the Backlog until API methods appear.
- Business analysis in a separate sprint
- Designing an interface
- Transfer to development
Such a scheme can stretch over three four-week sprints.
There is no perfect process, the process is good at the moment. Our process at the moment allows us to effectively solve the problems of the customer’s business. Naturally, the organization of project sprints does not completely cover the problems voiced at the beginning of the text. About how to overcome them completely - in the next article.
See also:
Business Intelligence Toolkit: Personal Experience
Organizing a Personal Knowledge Base at Evernote
Material Design: To the Moon and Back
Often companies think in terms of categories and solutions of the web and want to see all the basic functions, features, services (as if it were the main page of the site) on the launch page of their mobile application. This, to put it mildly, is not always justified, but requires argumentation.
2. The analyst makes up requirements that developers do not like
Developers who read requirements do not. There are analysts who, 10 times during the writing of requirements, discuss them with the developers.
3. Requirements become void at the testing stage.
You need to communicate with testers - they know how to break. It’s useful for the analyst to get a long list of “how it should work” tips before designing.
4. Fantastic design
Layouts must be feasible. Therefore, the requirements for interfaces and design reviews are needed.
5. The application should develop, and it should develop gradually.
It is impossible to implement all the features at once. Therefore, the set of tasks must be limited.
“Improvement is not necessary. Survival is a voluntary matter ”(c) Edward Demming
Sooner or later, any project, even in Agile and Scrum, comes to standardize processes. But perfection is impossible without a close focus on the process itself. It looks like this with us.
Sprint pulse
The standard sprint at Redmadrobot is 4 weeks. During this time, we manage to go from the formalization of the goal, its implementation in lines of code and rigorous testing to uploading a new version of the application in the App Store and Google Play.
First, we prepare the design requirements, and only then - the development.
- 3 weeks. Sprint candidate training
Participants:
PM - requests a set of tasks for the future Sprint
RO (Product Owner) from the customer - forms a set of features that are potential candidates for the new
BA sprint - processes information and clarifies open questions
Artifacts:
- a set of tasks for the future sprint in the form feature
- priorities from the customer
Tools: JIRA
The whole procedure is a clarification of the priorities of the previously planned roadmap.
- 2 weeks. Sprint Training and Scope Review
Participants:
BA - fixes requirements, cleans Impact Map of information that is too detailed and is not related to the
RO goal on the part of the customer - is responsible for business goals
UX-designer - helps to think through user goals and methods for achieving them
Artifacts:
- Impact Map
- description of users
- User Stories
- topology of stakeholders
- specification of external systems API
Tools: Xmind, Confluence
All tasks that come to us can be divided into two types :
- there are working API methods
- no methods
It is logical that the development of methods can take a fairly large amount of time. We try not to take such tasks into development, but we can prepare requirements for the development of methods, the interface and work out the design for the future sprint (2 week sprint).
To compile Impact Map you need to answer 4 questions:
- Why are we doing this? A good target is a problem and ideally follows the SMART format.
- Who will help us achieve this goal? It is important on this map to indicate not only a specific segment of users, but also all participants who can have an impact to achieve the goal. For example, a marketing employee in charge of a product.
- How should we influence this actor to help us achieve our goal?
- What will we actually implement?
At this stage, problem No. 1 is often resolved "Everyone wants to be on the main page."
Scope review
Participants: DEV, DES, QA, BA, PM, UX-designer.
Artifacts:
- sprint scopes, agreed and approved by the customer.
Tools: Confluence
This is an intermediate checkpoint between the appearance of the specification of requirements and interface requirements. It is determined how much time it will take for the team to complete this task, if there are stop factors that do not allow you to take the task into the sprint, labor costs are estimated. Scope is sent to PM for approval by Product Owner. After that, the sprint is fixed, and adding new features becomes impossible. “The application should develop, and it should develop gradually” - we deal with problem No. 5
- 1 Week. Design Interface Requirements and Design Review
Participants: BA, UX designer
Artifacts:
- Use Cases
- content restrictions
- non-functional requirements
Tools: Confluence
In the practice of preparing requirements, we use standard approaches to describe them: Use Cases (template proposed by Alistair Kobern ). Scripts interact well with previously prepared User Stories and cover them. Scenario development is carried out jointly with the UX designer and describes the future behavior of the system, which the designer needs to reflect. Going beyond this framework creates changes in requirements: content restrictions that are identified on the basis of the API specification and communication with the customer, as well as non-functional requirements.
NB! After preparing the requirements for the interface, we conduct an absentee review with the rest of the team. Gathering comments at an early stage eliminates the need for an unrealizable design.
Design review
Participants: DEV, DES, QA, BA, PM, UX Designer, PO
Artifacts:
- screen map
Tools: Confluence
As soon as they appear, finished screens are sent to the entire team for review. Checking layouts is carried out according to several indicators:
- For compliance with the initial requirements for the interface, as well as the prepared requirements for the mobile application
- To match the capabilities of the system
- In the case of a large number of comments, the design is sent for revision. If the verification stage with the team is passed, then the mock-ups are sent for approval to the customer.
We continue to solve the problem №4 “Fantastic design”, which we started to deal with at the previous stage
Case “My Beeline”
When the service “Number to choose” was implemented in the application, a ready-made design fell into our VA (as a legacy from the time when the project did not have full analytics). After analyzing, I found that the design is difficult to implement + our API did not support such an implementation + an extra set of screens were drawn that were not used in the application. The scope on the design was incorrectly defined.
We had to redraw everything.
1 week sprint. Coverage Layouts Requirement and Requirement Review
Participants: BA, UX designer
Artifacts:
- Impact Map
- user descriptions
- User Stories
- Use Cases
- non-functional requirements
- content restrictions
- specification of API of external systems
- functional requirements
The objective of this stage is to formally fix the agreements discussed earlier in the form of functional requirements for the developed system. Requirements are born from the interactions of team members and their joint decisions.
It helps:
- Maintain platform consistency.
- Keep all product requirements as well as decisions made in one place.
- Quickly bring new developers up to date.
- Formally coordinate the requirements with the customer (I agree that this is not entirely Agile, but this is a harsh reality).
- Work on the requirements of the whole team and cover open questions generated by testers, developers.
Requirement Review
Participants: DEV, DES, QA, BA, PM, UX designer
Artifacts:
- Impact map
- user descriptions
- User Stories
- Use Cases
- non-functional requirements
- content restrictions
- specification of external systems API
- functional requirements
Tools: Confluence
Tasks at this stage - make sure that the necessary set of requirements for development is fixed, whether they are clear to all team members and are interpreted the same way. When comments and comments appear, the requirements change and go through the re-review procedure, after which they are agreed with the customer.
Case “My Beeline” The
application is implemented on two platforms - Android and iOS; each platform and development team has its own team leader. It happens that these commands give out some solutions that are not synchronized with each other. I fix them in the requirements.
2 week sprint. Support for the team at the development stage and development of requirements for major tasks
Participants: BA, DEV, UX-designer
Artifacts:
- sprint scoop agreed by the customer
- specification of API external systems (if available)
Tools: Confluence
The tasks here are divided into two types . In the first case, the API specification is missing - the analyst, together with the development, prepares the specification of requirements for the Backend. It becomes the main one for the future map of screens and is taken into account in content restrictions. In the second case, there is a specification of the API of external systems, but the task is too large to completely go through the entire cycle from analysis to testing. Then the process follows the standard procedure described in the paragraph “Developing Interface Requirements and Design Review”. Then it goes to the next sprint, where it will be covered by the requirements for the mobile application and developed, or put off in the Backlog until API methods appear.
NB! Naturally, from time to time you have to work with tasks that, due to their size, cannot fall into the sprint. Then the following scheme is used:
- Business analysis in a separate sprint
- Designing an interface
- Transfer to development
Such a scheme can stretch over three four-week sprints.
Conclusion
There is no perfect process, the process is good at the moment. Our process at the moment allows us to effectively solve the problems of the customer’s business. Naturally, the organization of project sprints does not completely cover the problems voiced at the beginning of the text. About how to overcome them completely - in the next article.
See also:
Business Intelligence Toolkit: Personal Experience
Organizing a Personal Knowledge Base at Evernote
Material Design: To the Moon and Back