Backlog Refinement SWEN-610 By Dr ian mitchell (Own work) [CC BY-SA - - PowerPoint PPT Presentation

SWEN-610 Foundations of Software Engineering

Department of Software Engineering Rochester Institute of Technology

Backlog Refinement

By Dr ian mitchell (Own work) [CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0) or CC0], via Wikimedia Commons

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

• r 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

• ne 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
• f 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.

6 In Dev In Test Ready for Test Done

S1 (5) S2 (13) S3 (?) S4 (3) S5 (3) S9 (?)

Product Backlog Sprint Backlog

S10 (?) S11 (?) S6 (?) S7 (?) S8 (?) Refinement Meetings

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