Scrum Certification
Do your Sprint Planning Meetings last longer than 2 hours? Are there heated discussions about unclear requirements and does the Product Owner have a hard time to answer the questions? Is it normal that new detail requirements pop up during the Sprint you implement the according Product Backlog item? Do the developers just develop during a Sprint? Does the Product Owner gather all requirements and the developers do not have contact with users outside the Sprint Review?
If you answer these questions with “Yes”, you are probably not refining the Product Backlog and detail requirements for the next items in the Product Backlog prior to the Sprint Planning Meeting.
Product Backlog refinement is continuous requirements engineering. This is an important activity that has found its way into the newest version of the Scrum Guide finally. When being added to the Scrum Guide, it was renamed from Product Backlog grooming since grooming stands for bad things in certain cultures.
The live of a Product Backlog item
A Product Backlog item (a more general term than User Story) is changed many times from its initial creation until selected for a Sprint! Here an example how an item may evolve:
- When created it has a simple two word title only
- Two months later (in this example), the Product Owner summarizes a brief discussion with a stakeholder in four sentences and adds them to the item.
- One week later, the Scrum Team estimates the item for the first time. It records the estimation and a brief description of the most important discussion points.
- Two weeks later, a developer adds three acceptance criteria.
- One month later, the same developer adds a picture of a flipchart on which he documented the discussion with a user and the Product Owner.
- Another week, the developer adds a user interface sketch.
- Next day, the Scrum Team re-estimates considering the new information available.
During this time, the rank of the item in the Product Backlog has been increased and it will be realized in the next Sprint.
What is done during the Product Backlog refinement?
Product Backlog refinement has four goals:
- Clarifying and communicating higher ranked items until they are clear and understood by the Development Team (Conversation).
- Confirmation: Adding acceptance criteria to narrow the scope and defining when this item is done (Confirmation).
- Estimating items that are new or need to be re-estimated. Estimation with Planning Poker is a very good activity to foster discussion and find out whether an item is clear and understood by the Development Team.
- Splitting items that are too large for a Sprint before they could be subject of a Sprint Planning.
There are several excellent techniques to reach above listed goals: 3C’s (Card, Conversation, Confirmation), INVEST & SMART, Planning Poker, and Story Splitting Patterns to name a few. Each technique is worth an own blog. I will link them here when they are written…
When does Product Backlog refinement take place?
Product Backlog refinement is part of the Sprint. There is e.g. a 1 hour meeting in the mid of the Sprint and follow up meetings to clarify open questions bilateral or in smaller groups. Refinement may eat up to 10% of the Sprint capacity. I have seen teams investing up to 30% in early Sprints.
One team followed an interesting process: They started to discuss and estimate the item which was ranked highest in the Product Backlog and not yet ready for Sprint Planning. They set a timer to six minutes and when they could not come to a conclusion after this time, a developer got the job to clarify the open questions until the next meeting. Then, they continued with the next item. This method allowed them to discuss at least 10 items during the 1 hour meeting. Between two meetings, several developers were in charge to discuss items with users, stakeholders and the Product Owner.
Who refines the Product Backlog?
According the Scrum Guide, the Product Owner is responsible that the Product Backlog is kept up-to-date. Should he according to that clarifying open questions with stakeholders and refining items? No! If he would do most of the work, he would prevent direct communication between users and developers and act as a fence. This is exactly the situation that agile methods want to overcome.
It is the Development Team that does most of the work. Developers shall meet users and other stakeholders and talk to them directly. Direct communication is the key. The Product Owner has to assure that the developers talk to the right stakeholders and may accompany them.
When is a Product Backlog item clear and understood?
The Definition of Done (DoD) is well known. The Definition of Ready (DoR) is less known. This DoR determines when an item is ready for Sprint Planning. Both definitions are closely related to each other:
There are excellent descriptions of the Definition of Ready on the web, e.g. http://www.romanpichler.com/blog/product-backlog/the-definition-of-ready/. Be aware that a Definition of Ready shall not introduce formal requirements approval again, but help the Scrum Team to determine whether they have to talk more with stakeholders or should try realizing the item.
Is Product Backlog refinement an additional meeting/event in Scrum?
Until last year, the Scrum Guide has defined that Sprint Planning consists of two parts:
- Part 1: What can be done?
- Part 2: How will the chosen work be done?
Product Backlog refinement addresses part 1 of the Sprint Planning and – if done properly – replaces almost the entire part. Sprint Planning Meetings get shorter and more efficient. Product Backlog refinement is not an additional event, but it is Sprint Planning Meeting Part 1, leaving enough time for clarifications before the Sprint starts. It is not a meeting since most of the work is done by smaller groups and the entire Scrum Team only needs to be present to review and estimate the items.
Where to learn more about Product Backlog refinement?
Product Backlog refinement is an integral part of the Professional Scrum Developer training which is available in a Java and .NET edition.
A deeper look into requirements engineering is provided in the training Requirements engineering in an agile environment.
The training User Stories for Practitioners addresses refinements focusing on user stories.
Agile methods do not require extensive up-front requirements engineering and writing comprehensive specifications. The time saved is invested in the Software itself and results in earlier feedback. However, some of the saved time has to be re-invested during development for requirements discussions. Time overall is saved by not realizing (and therefore not specifying) features since they turn out not to be important and by shorter discussions since people can refer to already realized similar features and screens.
