Backlog Refinement
-
-
- What: Get User Stories ready:
- who/what/why
- acceptance criteria
- small enough to fit – split if necessary
- dependencies in place
- Sized in story points
- What: Get User Stories ready:
- Who: Dev. Team, PO, Scrum Master
- When: Approx. 2 hours per 2-week sprint
-
Agenda
- PO selects stories to refine
- PO describes story to team, takes questions, clarifies
- Add/discuss acceptance criteria
- Team splits stories that are too big
- Identify external dependencies if any
- Team estimates story sizes using planning poker
- Team confirms story meets definition of ready
Outcomes
- Refined stories meeting definition of ready
- Stories estimated in points
- Sufficient quantity of refined stories available consistent with team’s velocity or capacity for next sprint
Story Points Do’s and Don’ts
- Equating Story Points to just complexity, uncertainty or value. (points <> value). “Story points represent the effort involved to deliver a product backlog item” – Mike Cohn
- Translating story points to hours.
- Averaging story points at Planning Poker. Teams should push to understand assumptions behind differing estimates and select the best one.
- Adjusting story point estimates during a sprint. Stick with original estimates.
- Not story pointing bugs (or other backlog items). Point all backlog items.
- Adjusting reference PBI’s each sprint. Have a consistent reference point, otherwise velocity will be meaningless.
- Re-pointing unfinished/carried over PBI’s – keep the original estimates
- Adjusting a story point estimate because a specific team member will work on it.
SAFe Considerations
- In scrum, we have a single product backlog, owned and managed by a single Product Owner. A scrum PO is the Voice of the Customer and is responsible for all product-related questions including functional requirements, non-functional requirements, priorities and tradeoff decisions. In the SAFe framework, product requirements originate at a Portfolio Level, beginning life as epics that represent business initiatives, identified for the purpose of strategy realization. Once epics have been sufficiently defined, ranked and approved, they are then elaborated further into features which are maintained in a Program Backlog. This Program Backlog is essentially the scrum product backlog, however is shared between multiple teams (up to 12 teams in an Agile Release Train). Initial refinement of items from the Program Backlog into iteration-sized slices of user functionality (user stories) happens during a PI Planning event. This is done so that an estimate of how much of the Program Backlog can be delivered in an upcoming Program Increment – usually a 10-week time-box. During a PI Planning event however, there is usually insufficient time available to craft user stories into a full definition of ready, and so further refinement sessions are necessary, which are built into a team’s scrum calendar in the usual way.
- An initial set of stories may have been identified during PI Planning as part of the Story Mapping exercise that each team undertakes in order to break features from the Program Backlog into story-sized slices of functionality that can be delivered within iteration-sized timeboxes. Given the time constraints within the PI Planning event, it is not usually possible to sufficiently refine a large number of stories to meet a full definition of ready (DoR), and these initial set of stories may be fairly crude one-line summaries of intended behavior. Once the team has refined these stories to a definition of readiness, which includes adding acceptance criteria and a size estimate, they may have needed to split some of these stories, and indeed have identified additional functionality required by features. It is important in these circumstances to keep a watch on any additional scope or demands on development capacity that may impact the PI Objectives of the program, and to ensure that these issues and any necessary tradeoffs are addressed promptly.