The purpose of Product Backlog Refinement is rather easy to understand, but practicing it effectively can be challenging for new teams. I will introduce a few tips to help Scrum teams prepare their sprints more confidently with Acceptance Criteria and Task breakdown.
The art of visualizing work
Regardless of the tool (Physical board, Jira, Miro, etc.) used by a team, the fundamental principle that we want to keep in mind is Transparency.
Transparency is made possible by visualizing important information to the team so that they can make better decisions timely, and focus on what really matters.
Too much information creates noise and makes it difficult to grasp the big picture or detect warning signals. I strongly recommend to start small, and then add progressively some data based on actual needs. Some data may not be serving any purpose over the time, don't be afraid of removing it.
Acceptance Criteria to answer the question: "is the work done?"
Acceptance Criteria is not part of the Scrum Guide, yet it is used by many Scrum teams to avoid waste coming from:
- doing more than necessary (overwork)
- debating whether the work is done (extra communication)
- not meeting user's expectation (poor quality)
Acceptance Criteria is a set of conditions required for the customer, Product Owner, or stakeholder(s) to accept the work done by the team.
Acceptance Criteria is usually expressed as a checklist. Each item should be:
- Clear, so that everyone understands them
- Concise, so that there’s no ambiguity (it should be answered by yes, or no)
- Testable by anyone in the team
- Focused on providing user value
While defining some Acceptance Criteria, beware of the following anti-patterns :
- Too vague (using ambiguous words such as "some", "many", "information", etc.)
- Too descriptive (eg. "There is a Download icon the Video details screen")
- Rephrasing the Product Backlog Item / User Story
- Too many criteria (the example above is already indicating that the User Story should be split into smaller ones)
- Made after the fact (writing Acceptance Criteria once the work has started/is finished)
Acceptance Criteria should primarily focus on the user value, therefore it makes sense for the Product Owner to gather expectations and draft the Acceptance Criteria. Yet, it does not stop here, all the Scrum team holds different perspectives on what should be met in order to deliver the best product to the user. Therefore completing the Acceptance Criteria for a Product Backlog Item / User Story requires collaboration from the entire Scrum team. This is usually done during the Product Backlog Refinement and the Sprint Planning.
Breaking down work into small, actionable tasks
Many teams stop their Sprint Planning as soon as they have defined a Sprint goal (Why) and identified a list of Product Backlog Items to deliver (What). However, they often miss the opportunity to clarify what steps are required to complete the work, and how they will coordinate in order to deliver value and achieve their goal (How).
When working with teams new to Scrum, I usually recommend to break down each Product Backlog Item into small, and specific tasks. As the granularity of the work increases, additional information may emerge to the team:
- If the Product Backlog Item was already estimated, is this estimation still valid compared to the number of tasks identified?
- When having many tasks for one Product Backlog Item, would it make sense to break it down?
- Is each task contributing to validate the Acceptance Criteria? If not, can it be discarded?
- What might be the best order for completing all tasks?
- Is there any opportunity for transferring skills and knowledge between developers?
After the Sprint has started, some additional tasks may be discovered. In such case, add the new tasks to the board so that all developers can re-coordinate with new information in their hands.
These two practices require discipline at first. Yet I encourage new teams to trust the process and give themselves a chance to experience the benefits that they can get out from defining clear Acceptance Criteria and breaking down work into small and actionable tasks.
- Using Acceptance Criteria helps the scrum team focus on delivering the value identified by the Product Owner, no more, no less.
- Clear Acceptance Criteria makes it possible for Scrum teams to test the Product increment and deliver the expected quality to the user.
- Breaking down a Product Backlog Item into actionable tasks makes it possible for the developers to collaborate on the same work, and avoid multitasking.
- Visualizing all tasks can give a good indication whether the estimate is accurate enough.
- Visualizing the tasks and their progress helps the Scrum team detect earlier when something does not go according to the plan, and take appropriate measures timely.
