By Yi Lv
When do requirement analysis and design activities happen in the Scrum framework? How is our understanding of requirement and design analysis valuable in the Scrum framework? This article describes how these elements flow through Sprints within the Scrum framework.
Requirement analysis is one of the major activities in backlog grooming (the others are estimating and splitting). Once the Product Owner gets an idea by working with customers and adds one vague item into Product Backlog, the item will be groomed for the first time. Considering priority, this item and other smaller items are groomed through several rounds while the Team gets ready for Sprint Planning. The clarity of the items advances in each round of grooming. Acceptance criteria may be drafted in the grooming rounds before Sprint Planning. In the first part of the Sprint Planning Meeting, the requirement analysis continues. If you are able to continuously groom properly, the requirements will be well understood by that time. However, since items are selected in the Sprint Planning Meeting, only then is the Team sure that they are working on them. The Team normally identifies further points (e.g. exact scope, sad path scenario) to be clarified. This may be conducted by working out more details in the acceptance tests. The requirement analysis activity does not stop in the first part of the Sprint Planning Meeting, but continues in the second part and during the actual Sprint. In the second part of the Sprint Planning Meeting, while you are decomposing tasks, the ambiguity in requirement may surface again and be clarified. During the Sprint, test case design, modeling workshop, requirement discussion while designing and coding, and discovery from exploratory testing all contain some element of requirement analysis. Even in the Sprint Review, you will see requirement analysis activity through feedback and suggestion for improvement (new items).
When do we start design? Traditionally, we start design to move from problem domain to solution domain immediately once we get big Product Backlog items. This early move reduces the flexibility in terms of prioritization, which is not recommended in Agile development. We continue to work in the problem domain by keeping the customer orientation as much as possible while splitting the items. The splitting in the problem domain happens in backlog grooming. We also estimate the size of items in backlog grooming. Sometimes, you will have difficulty in estimating the item size, which may be caused by either vague requirements or a lack of experience. If the requirements are vague, requirement analysis in further rounds of grooming helps. If the solution is unknown, architecture or a design spike item can be added in the Product Backlog. This item is normally time-boxed, and its done criteria differ from those of normal backlog items. The output is the sufficient understanding to enable your estimating and planning. In the context of multiple teams working on the same code base, a joint design workshop may be conducted to synchronize the design across teams. In the second part of the Sprint Planning Meeting, the Team commits how much to do in the coming Sprint. In order to make the commitment, the Team normally makes the detailed plan by decomposing items into tasks and estimating those tasks. The commitment may be made based on velocity, but the Team may still think of tasks necessary for them to get the committed items done. How do you determine the tasks? You design. In the second part of Spring Planning, some teams jump into the task decomposition, and get a similar list of tasks such as design, coding, unit testing, review, and functional testing. This indicates a lack of design. How much design do we do in the Sprint Planning Meeting? It needs to be sufficient to support planning. The purpose of Sprint Planning is not design, even though there is a design element in the planning meeting. Besides, the planning meeting is constrained by a time-box, so the Team must find a way to make the best of the time. Design continues in the Sprint. The Team may organize a design workshop, or have an ad-hoc modeling discussion while coding, and coding itself is design. Our design is considered done when the item is done.
In conclusion, you can see the value of requirement understanding and design in the following Scrum activities (major ones in bold).
Requirement: backlog grooming (several rounds) -> Sprint Planning part 1 -> Sprint Planning part 2 -> Sprint -> done -> sprint review
Design: backlog grooming -> spike item (when necessary) -> Sprint Planning part 2 -> Sprint -> done
This flow allows for requirement analysis and design within the Scrum framework.
