Scrum sprint simulation. We solve problems of interaction with the client and within the team.
"The mobile application must be" alive ", the user must see that the project is developing"
We at Redmadrobot work on Agile and Scrum agile methodologies. As you know, they imply considerable freedom in how sprints are organized on projects — each company selects a convenient model for itself. Cases - information about 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 AA.
1. The client wants to see everything at once on the main screen.
Often, companies think in terms of the categories and solutions of the web and want to see all the main functions, features, and services on the launch page of their mobile applications (as if this were the main page of the site). This, to put it mildly, is not always justified, but requires argument.
2. The analyst invents requirements that developers are not satisfied with.
There are no developers who read the requirements. There are analysts who, 10 times while writing requirements, discuss them with the developers.
3. Requirements become void at the testing stage.
We need to communicate with testers - they know how to break. It is useful for the analyst to get a large list of “how it should work” tips before starting the design.
4. Fantastic design
Layouts must be implementable. Therefore, we need requirements for interfaces and design review.
5. The application must evolve, and it must evolve gradually
It is impossible to implement all features at once. Therefore, the set of tasks must be limited.
“It is not necessary to cultivate. Survival is voluntary ”(c) Edward Demming
')
Sooner or later, any project, even in Agile and Scrum, comes to standardize processes. But improvement is impossible without a close focus on the process itself. We have it looks like this.
The standard sprint in Redmadrobot is 4 weeks. During this time, we manage to go from the formalization of the goal, its implementation in lines of code and thorough testing to fill the new version of the application in the App Store and Google Play.
First, we prepare the requirements for design and only then - for development.
Participants:
PM - Requests a set of tasks for the future sprint
RO (Product Owner) by the customer - forms a set of features that are potential candidates for a new sprint
BA - processes information and clarifies open questions
Artifacts:
- a set of tasks-candidates for the future sprint in the form of features
- priorities from the customer
Tools: JIRA
The whole procedure is the specification of the priorities of the previously planned roadmap.
Participants:
BA - captures the requirements, clears the Impact Map from information that is too detailed and not relevant to the goal
Customer side RO - responsible for business objectives
UX-designer - helps to think about the goals of users and methods for achieving them
Artifacts:
- Impact Map
- description of users
- User Stories
- stakeholder topology
- external system API specification
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 quite a lot of time. We try not to take such tasks into development, but we can prepare the requirements for the development of methods, the interface, and work out the design for the future sprint (2 week sprint).
To compile the Impact Map, you need to answer 4 questions:
At this stage, problem number one is often solved: “Everyone wants to be on the main one”.
Participants: DEV, DES, QA, BA, PM, UX-designer
Artifacts:
- the sprint skoup agreed and approved by the customer
Tools: Confluence
This is an intermediate checkpoint between the appearance of the specification requirements and interface requirements. It is determined how long it will take for the team to accomplish this task, whether there are stop factors that do not allow to take the task into the sprint, labor costs are estimated. Scope is sent by PM for approval with the Product Owner. After this, the sprint is fixed, and adding new features becomes impossible. “The application should evolve, and it should evolve gradually” - we deal with the problem number 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 for their description: Use Cases (a pattern proposed by Alistair Cobern ). Scripts interact well with previously prepared User Stories and cover them. The development of scenarios goes together with the UX-designer and describes the future behavior of the system, which must be reflected by the designer. Going beyond this framework generates changes in requirements: content restrictions that are identified based on 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 they appear, ready-made screens are sent to review the entire team. Check layouts carried out on several indicators:
We continue to solve the problem â„–4 "Fantastic design", which began to be dealt with at the previous stage
Participants: BA, UX Designer
Artifacts:
- Impact Map
- description of users
- User Stories
- Use Cases
- non-functional requirements
- content restrictions
- specification of external systems API
- functional requirements
The task of this stage is the formal fixation of the previously discussed agreements in the form of functional requirements for the system being developed. Requirements are born from team members' interactions and their joint decisions.
It helps:
Participants: DEV, DES, QA, BA, PM, UX-designer
Artifacts:
- Impact map
- description of users
- User Stories
- Use Cases
- non-functional requirements
- content restrictions
- specification of external systems API
- functional requirements
Tools: Confluence
The tasks at this stage are to ascertain whether the necessary set of requirements is fixed for the development, if they are understood by all team members and are interpreted in the same way. When comments and comments appear, the requirements change and undergo a re-review procedure, after which they are agreed with the customer.
Participants: BA, DEV, UX-designer
Artifacts:
- the sprint skop agreed by the customer
- external system API specification (if available)
Tools: Confluence
Tasks here are divided into two types . In the first case, there is no API specification — the analyst, together with the development, is preparing the specification of requirements for Backend. It becomes the basis for a future map of the screens and is taken into account in the content restrictions. In the second case, there is a specification of the API of external systems, but the task is too big to completely go through the whole cycle from analysis to testing. Then the process follows the standard procedure described in “Developing Interface Requirements and Design Review” . Then it is sent to the next sprint, where it will be covered by the requirements for the mobile application and developed, or put it aside in the Backlog until the API methods appear.
- Business analysis in a separate sprint
- Interface design
- Transfer to development
Such a scheme can stretch into three four-week sprints.
The ideal process does not happen, the process is good at the moment. Our current process allows us to effectively solve the problems of the customer’s business. Naturally, the organization of sprints on projects does not fully cover the problems voiced at the beginning of the article. How to overcome them finally - in the next article.
See also:
Business Analytics Toolkit: Personal Experience
Organizing your personal knowledge base in Evernote
Material Design: to the moon and back
We at Redmadrobot work on Agile and Scrum agile methodologies. As you know, they imply considerable freedom in how sprints are organized on projects — each company selects a convenient model for itself. Cases - information about 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 AA.
1. The client wants to see everything at once on the main screen.
Often, companies think in terms of the categories and solutions of the web and want to see all the main functions, features, and services on the launch page of their mobile applications (as if this were the main page of the site). This, to put it mildly, is not always justified, but requires argument.
2. The analyst invents requirements that developers are not satisfied with.
There are no developers who read the requirements. There are analysts who, 10 times while writing requirements, discuss them with the developers.
3. Requirements become void at the testing stage.
We need to communicate with testers - they know how to break. It is useful for the analyst to get a large list of “how it should work” tips before starting the design.
4. Fantastic design
Layouts must be implementable. Therefore, we need requirements for interfaces and design review.
5. The application must evolve, and it must evolve gradually
It is impossible to implement all features at once. Therefore, the set of tasks must be limited.
“It is not necessary to cultivate. Survival is voluntary ”(c) Edward Demming
')
Sooner or later, any project, even in Agile and Scrum, comes to standardize processes. But improvement is impossible without a close focus on the process itself. We have it looks like this.
Sprint pulse
The standard sprint in Redmadrobot is 4 weeks. During this time, we manage to go from the formalization of the goal, its implementation in lines of code and thorough testing to fill the new version of the application in the App Store and Google Play.
First, we prepare the requirements for design and only then - for development.
- 3 week. Sprint Candidate Training
Participants:
PM - Requests a set of tasks for the future sprint
RO (Product Owner) by the customer - forms a set of features that are potential candidates for a new sprint
BA - processes information and clarifies open questions
Artifacts:
- a set of tasks-candidates for the future sprint in the form of features
- priorities from the customer
Tools: JIRA
The whole procedure is the specification of the priorities of the previously planned roadmap.
- 2 week. Sprint Candidate and Scope Review Training
Participants:
BA - captures the requirements, clears the Impact Map from information that is too detailed and not relevant to the goal
Customer side RO - responsible for business objectives
UX-designer - helps to think about the goals of users and methods for achieving them
Artifacts:
- Impact Map
- description of users
- User Stories
- stakeholder topology
- external system API specification
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 quite a lot of time. We try not to take such tasks into development, but we can prepare the requirements for the development of methods, the interface, and work out the design for the future sprint (2 week sprint).
To compile the Impact Map, you need to answer 4 questions:
- What are we doing this for? A good goal is a problem and ideally meets the SMART format.
- Who will help us achieve this goal? It is important to indicate on this map not only a certain segment of users, but also all participants who may have an influence on achieving the goal. For example, the employee of the marketing department responsible for the product.
- How should we influence this actor to help us achieve our goal?
- What will we actually implement?
At this stage, problem number one is often solved: “Everyone wants to be on the main one”.
Scope review
Participants: DEV, DES, QA, BA, PM, UX-designer
Artifacts:
- the sprint skoup agreed and approved by the customer
Tools: Confluence
This is an intermediate checkpoint between the appearance of the specification requirements and interface requirements. It is determined how long it will take for the team to accomplish this task, whether there are stop factors that do not allow to take the task into the sprint, labor costs are estimated. Scope is sent by PM for approval with the Product Owner. After this, the sprint is fixed, and adding new features becomes impossible. “The application should evolve, and it should evolve gradually” - we deal with the problem number 5
- Week 1. Designing 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 for their description: Use Cases (a pattern proposed by Alistair Cobern ). Scripts interact well with previously prepared User Stories and cover them. The development of scenarios goes together with the UX-designer and describes the future behavior of the system, which must be reflected by the designer. Going beyond this framework generates changes in requirements: content restrictions that are identified based on 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. Collecting comments at an early stage allows you to avoid drawing an unrealizable design.
Design Review
Participants: DEV, DES, QA, BA, PM, UX-designer, PO
Artifacts:
- screen map
Tools: Confluence
As they appear, ready-made screens are sent to review the entire team. Check layouts carried out on several indicators:
- Compliance with the initial requirements for the interface, as well as prepared requirements for the mobile application
- Compliance with the system capabilities
- In the case of a large number of comments design is sent for revision. If the verification phase with the team is completed, the layouts are sent for approval to the customer.
We continue to solve the problem â„–4 "Fantastic design", which began to be dealt with at the previous stage
Case "My Beeline"
When the application “Number to choose” was implemented in the application, we already had a ready-made design in VA (as a legacy from the time when the project did not have full-fledged 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 was 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 Layout Requirements and Requirement Review
Participants: BA, UX Designer
Artifacts:
- Impact Map
- description of users
- User Stories
- Use Cases
- non-functional requirements
- content restrictions
- specification of external systems API
- functional requirements
The task of this stage is the formal fixation of the previously discussed agreements in the form of functional requirements for the system being developed. Requirements are born from team members' interactions and their joint decisions.
It helps:
- Maintain platform uniformity.
- Store all product requirements, as well as decisions taken in one place.
- Quickly introduce new developers.
- Formally coordinate the requirements with the customer (I agree that this is not exactly Agile, but such is the 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
- description of users
- User Stories
- Use Cases
- non-functional requirements
- content restrictions
- specification of external systems API
- functional requirements
Tools: Confluence
The tasks at this stage are to ascertain whether the necessary set of requirements is fixed for the development, if they are understood by all team members and are interpreted in the same way. When comments and comments appear, the requirements change and undergo a 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 lead. It happens that these commands give some solutions that are not synchronized with each other. I fix them in the requirements.
2 week sprint. Support of the team at the development stage and elaboration of requirements for major tasks
Participants: BA, DEV, UX-designer
Artifacts:
- the sprint skop agreed by the customer
- external system API specification (if available)
Tools: Confluence
Tasks here are divided into two types . In the first case, there is no API specification — the analyst, together with the development, is preparing the specification of requirements for Backend. It becomes the basis for a future map of the screens and is taken into account in the content restrictions. In the second case, there is a specification of the API of external systems, but the task is too big to completely go through the whole cycle from analysis to testing. Then the process follows the standard procedure described in “Developing Interface Requirements and Design Review” . Then it is sent to the next sprint, where it will be covered by the requirements for the mobile application and developed, or put it aside in the Backlog until the API methods appear.
NB! Naturally, from time to time you have to work with tasks that, because of their size, cannot get into the sprint. Then the following scheme is used:
- Business analysis in a separate sprint
- Interface design
- Transfer to development
Such a scheme can stretch into three four-week sprints.
Conclusion
The ideal process does not happen, the process is good at the moment. Our current process allows us to effectively solve the problems of the customer’s business. Naturally, the organization of sprints on projects does not fully cover the problems voiced at the beginning of the article. How to overcome them finally - in the next article.
See also:
Business Analytics Toolkit: Personal Experience
Organizing your personal knowledge base in Evernote
Material Design: to the moon and back
Source: https://habr.com/ru/post/256389/
All Articles