Coaching teams that are new to Agile and Scrum is often about finding the right trade-offs for that team and the domain they are working on. No one size fits all, which is why implementing Agile is often hard.
One of the trade-offs is in choosing which meeting the product backlog ordering and estimating is done. Typically teams do this in a combination of two events. These are the product backlog refinement and the sprint planning session.
Backlog refinement versus Sprint planning
In the Scrum Guide, there is no official meeting for backlog refinement. The guide states that the refinement process is an ongoing act of adding detail, estimates, and order to items in the backlog. The team decides how and when this is done, and the guide recommends that the process takes no more than 10% of the capacity for the team.
In practice, the refinement session duration is dependent on:
- how new the backlog is
- the size of the backlog
- how many people turn up the refinement session
- how much detailed estimating is left to the sprint planning meeting
The Scrum Guide states that the meeting called Sprint Planning is split into two topics. These answer the questions of a) what can be done in the sprint and b) how the work will get done.
Looking at these definitions, we can see that from backlog refinement we want to produce a backlog that is sized and ordered, and from the sprint planning, we want to determine what to take into the sprint and how we will do it.
During sprint planning, the guide recommends designing the system to see how it will be built. This often changes the estimation of the items and therefore estimation or re-estimation is often part of Sprint planning as a bi-product of deciding how to complete the items.
In addition, teams often re-estimate items because it is the last responsible moment to do so. This is the point at which the latest information is available before committing the items to the Sprint Backlog.
Designing the system in Sprint Planning needs to be done quickly, and Scott Ambler’s light weight models are essential in making this type of collaborative exercise successful in the time frame.
The Scrum Guide has removed the concept of having a part 1 and part 2 for Sprint planning, which in my opinion is unfortunate. The two topics relate to the old parts close enough, but having distinct separation was very useful when operating across more than one team with a single product owner. Large Scale Scrum (LeSS) shows that we can scale software development and still keep the benefits of Scrum by having a single product backlog and product owner. This is logistically possible as the PO can attend the overall Sprint Planning part 1 session, and then the teams can break away into part 2 as individual teams.
In this case, it is important to have as little time taken up in Sprint Planning part 1 as possible on clarification, as all teams are present, and any delay or debate often results in many people in a meeting that is not useful.
Defining a starting point
To find the trade-off of when to prioritise, clarify and size, I have found this generic starting point explain what to do at each meeting. After some time, you can then be adapt the process to your team and domain.
Backlog refinement
Backlog Refinement is the POs responsibility. During the sprint, the PO keeps the backlog up to date by re-prioritising as appropriate, adding new stories and removing anything that is never going to be done. Most of the work is generally done by the PO outside of the refinement meeting. Only the work that cannot be done by the PO alone is brought into the refinement session.
For items than cannot be added by the PO such as technical stories, and tasks that cannot be completed by the PO, such as estimating, the PO invites the appropriate members of the development team to the refinement session. The development team is therefore a stakeholder too.
The refinement sessions usually happen once or twice a sprint usually just before the end of the last week. The purpose of the meeting is to provide the development team with an overview and clarification of the backlog. The teams can focus on the items with higher priority for longer duration. The development team can relatively size the backlog of less than 50 items in less than one hour using techniques such as this one described in the AWA blog.
The output of this meeting should be a DEEP backlog. With the highest priority stories following the INVEST approach or similar.
Sprint Planning
The team are already familiar with the items from attending Backlog Refinement, and therefore can focus on further detailed clarification, lightweight modelling or discussion, re-estimation, creation of the sprint goal and the sprint backlog.
In the case of multiple teams Scrum, the first part (Sprint planning 1) is all the feature teams gaining clarification, choosing stories for their sprint, and working out dependencies. The second part (Sprint planning 2) is individual teams modelling to decide how, and making sure they can complete the items in a single sprint.
The PO is typically on hand for further clarification and negotiation during the second part but floats amongst the teams.
Curious about Agile ways of working? We answer your most frequently asked questions here.
Pingback: Refinement/Grooming, and Sprint Planning – Test Analyst Notes