More than plain vanilla scrum. Common practice with requirements
Recently, an article by Mike Cohn was published on the Scrum portal about generally accepted practices in Scrum - practices that are quite common in Scrum projects, but are not the basic rules of Scrum.
Scrum encourages such additions and is specially designed minimalist , so that teams can add what they like. Do not confuse such improvements process with the infamous Skramnom. Unlike the latter, the added practices improve the process, increasing the efficiency of product release and leveling the work flow.
Today I want to share a lot of these practices gathered around working with requirements. Over the past few years, I have repeatedly had the opportunity to observe the scenes of successful teams as an agile coach and talk about them at Certified ScrumMaster trainings as a scrum coach.
')
In no case do I pretend to be a full practitioner and will be glad to hear the additions. Some of these practices deserve separate articles - this is work in progress.
So:
Structured requirements maps
The project's vision and high-level requirements are inconvenient to store as a backlog. These are not one-dimensional listings. Ideas are lists with complex links. Modern Product Owners and analysts use specialized techniques and formats to work with project ideas. Two popular specialized techniques are user story mapping and impact mapping - specialized mind maps.
Currently, not many electronic tools support the creation of such maps. But Google docs for story mapping and ordinary mind-mapping tools for influence maps do a good job with these tasks.
It works like this: project ideas in the early phase are drawn up in the form of visual maps. This is a convenient and natural way. After that, as the project progresses, the Product Owner during the grooming sessions (see below) layers user stories from these cards. Thus, the backlog of a product is never full and consists of a small, manageable subset of the requirement elements.
Product Owners Team
In most of the projects that I have witnessed over the past few years, the study of requirements is doing more than one person. Sometimes this is a couple of people, more often - a group consisting of product managers, analysts, domain specialists, architects, representatives of end users.
Such groups are now called the Product Owner Team.
This practice is not at all incompatible with the Scram rule of having only one Product Owner. Such a team is managed by one strategic manager, who has a high-level vision of the product, directs and coordinates the work of the group.
Backlog Grooming Sessions
When and by whom is backlog made? Doing this work between sprints leads to a cut load on the Product Owner Team and often delays the start of sprints, worsening the quality of the plans.
Instead, it is a common practice to hold scheduled backlog workouts during sprints. In foreign literature, the term backlog grooming is used (literally, “to look after”). During these sessions, participants:
Analysis Process Boards
As the Product Owner Team works and their grooming sessions, many artifacts and requirements arise at different phases of the analysis. For the convenience of managing the flow of this work, Kanban boards are used.
An example of the states of such a board:
As you can see, the last column of such a board is the actual backlog of the product. These ready-made stories fall into the plans of the sprint.
Such a board can be easily combined with a development board, which will provide a single project management board from idea to release.
What other requirements practices do you use at Scrum?
In the following articles, I will share my observations on common practices of teamwork, planning, tracking the progress of the project and deliveries.
Scrum encourages such additions and is specially designed minimalist , so that teams can add what they like. Do not confuse such improvements process with the infamous Skramnom. Unlike the latter, the added practices improve the process, increasing the efficiency of product release and leveling the work flow.
Today I want to share a lot of these practices gathered around working with requirements. Over the past few years, I have repeatedly had the opportunity to observe the scenes of successful teams as an agile coach and talk about them at Certified ScrumMaster trainings as a scrum coach.
')
In no case do I pretend to be a full practitioner and will be glad to hear the additions. Some of these practices deserve separate articles - this is work in progress.
So:
Common practice of working with requirements in Scrum
Structured requirements maps
The project's vision and high-level requirements are inconvenient to store as a backlog. These are not one-dimensional listings. Ideas are lists with complex links. Modern Product Owners and analysts use specialized techniques and formats to work with project ideas. Two popular specialized techniques are user story mapping and impact mapping - specialized mind maps.
Currently, not many electronic tools support the creation of such maps. But Google docs for story mapping and ordinary mind-mapping tools for influence maps do a good job with these tasks.
It works like this: project ideas in the early phase are drawn up in the form of visual maps. This is a convenient and natural way. After that, as the project progresses, the Product Owner during the grooming sessions (see below) layers user stories from these cards. Thus, the backlog of a product is never full and consists of a small, manageable subset of the requirement elements.
Product Owners Team
In most of the projects that I have witnessed over the past few years, the study of requirements is doing more than one person. Sometimes this is a couple of people, more often - a group consisting of product managers, analysts, domain specialists, architects, representatives of end users.
Such groups are now called the Product Owner Team.
This practice is not at all incompatible with the Scram rule of having only one Product Owner. Such a team is managed by one strategic manager, who has a high-level vision of the product, directs and coordinates the work of the group.
Backlog Grooming Sessions
When and by whom is backlog made? Doing this work between sprints leads to a cut load on the Product Owner Team and often delays the start of sprints, worsening the quality of the plans.
Instead, it is a common practice to hold scheduled backlog workouts during sprints. In foreign literature, the term backlog grooming is used (literally, “to look after”). During these sessions, participants:
- make up user stories (based on requirements and current needs maps)
- decompose major stories into small ones
- evaluate the complexity of the work
- detail the stories with design sketches and user interactions, test cases and examples
- discuss ways to implement
- perform and analyze fast prototypes
Analysis Process Boards
As the Product Owner Team works and their grooming sessions, many artifacts and requirements arise at different phases of the analysis. For the convenience of managing the flow of this work, Kanban boards are used.
An example of the states of such a board:
| New ideas
(five) | Detailing
(3) | Ready for grooming with the team
(3) | Prototyping
(3) | Interface development
(3) | ... | Ready for planning to sprint
(ten) |
As you can see, the last column of such a board is the actual backlog of the product. These ready-made stories fall into the plans of the sprint.
Such a board can be easily combined with a development board, which will provide a single project management board from idea to release.
What other requirements practices do you use at Scrum?
In the following articles, I will share my observations on common practices of teamwork, planning, tracking the progress of the project and deliveries.
Source: https://habr.com/ru/post/170767/
All Articles