Backlog Refinement SWEN-610 By Dr ian mitchell (Own work) [CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0) or CC0], via Wikimedia Commons Foundations of Software Engineering Department of Software Engineering Rochester Institute of Technology
Refinement of the Product Backlog makes sprint planning easier. User story statements have little detail. So acceptance criteria need to be defined. These provide enough detail to design a solution. The solution tasks provide the basis for determining story points. • Using Planning Poker in a future lesson Story points provide the information for doing sprint planning. • And of course the team's velocity (capacity) Backlog refinement is also called backlog grooming. 2
Acceptance criteria come from the Product Owner or user representatives. There are many ways of gathering additional requirement detail. • See the Defining Project Requirements lesson • Here we'll consider brainstorming sessions There are two main ways of doing backlog refinement: 1. Meet as a whole team with the Product Owner to discuss the stories together 2. Meet in small groups to discuss individual stories 3
The main backlog refinement technique is to have one long meeting with the whole team. Review each un-groomed story in priority order. • The product backlog must have enough stories groomed to be ready for the next sprint • The Product Owner leads the discussion and drives the exploration of the acceptance criteria • The Dev Team asks questions to further elaborate the acceptance criteria The whole Dev Team is involved • After criteria are known the team can do an estimate of story points The meeting should be time-boxed but could take up to four hours 4
Alternatively a team could use more, small, shorter meetings on specific stories. A developer is assigned a story to groom. • They are responsible for meeting with a user rep • Other members may be involved as needed • They work on the acceptance criteria These meetings can be shorter and easier to schedule. • The acceptance criteria are fleshed out enough for an estimate • But the whole team needs to be present to do Planning Poker The result is that the Sprint Planning meeting takes longer for the team to calculate story points. 5
During Sprint X you refine stories for Sprint X+1. Product Sprint Ready In Test Done In Dev Backlog Backlog for Test S1 (5) S3 (?) S4 (3) S2 (13) S6 (?) S5 (3) S7 (?) S8 (?) Refinement Meetings S9 (?) S10 (?) S11 (?) 6
Let's review: What makes good acceptance criteria? Like stories, focus on the what not the how . Use a Given/When/Then format: • GIVEN some precondition WHEN I do some action THEN I expect some result • Given that I'm not signed-on when I'm visit the Home page then I expect to clearly see how to Sign-on. • Given that some other player has already signed-on with my name when I attempt to sign-in with my name then the system should reject the request with an error message and re-render the Sign-on form. 7
A developer then fleshes out a skeleton design. Evolve the analysis models: • Explore new domain concepts • Alter existing domain model • Does the story alter the web interface? Then update the Statechart with your proposed states. The design is very high-level: • Create or modify Views and Controllers in the UI tier • Create or modify Services in the Application tier • Create or modify Entity or Value Objects in the Model tier • Create or modify any other helper component • Refactoring existing code to improve the overall design 8
These descriptions become tasks in the story's Trello card. 9
Recommend
More recommend
