During the Sprint planning, some of the Product Backlog Items (PBIs) are moved into the Sprint backlog based on the team’s capacity, to be completed in the stipulated Sprint timeframe.
In spite of doing it, there are chances that the team often falls short of completing scoped items.
Sprint after Sprint.
Even with retrospectives in place.
There are a few things that are often overlooked or ignored for a Sprint to be effective.
In this article, we shall look at 3 such items.
If you find the article useful, take a moment to share it with someone that may need it.
1. Ensure everyone on the team understands DoR and DoD
How would you hit a goal if you don’t know what it looks like?
Interestingly, many Sprint teams do not have a clearly defined understanding of the Definition of Ready and Definition of Done.
Definition of Ready defines the state that a Product Backlog Item (PBI) should be in when it is moved into the Sprint backlog.
A sample DoR checklist could be something like this –
Definition of Done defines the state of the task when it is marked as ‘Complete’ by the team member.
An example of DoD checklist would look like this –
These are validated by following the predefined checklist.
Unless these are defined ahead of time and understood by the team members, uncertainties & misunderstandings can easily creep into the Sprint and the outcome could be compromised.
You may also enjoy:
- 15 top PMP strategies from 327+ PMPs I’ve interviewed
- 19 daily PM challenges you face & how to deal with ’em
- A step-by-step guide to create your personal brand!
- PMP Exam Study in 2022: 5 Traps You Must Avoid
- 9 insane PMP prep tips, from 9 years of coaching
Grab my free PMP course to get started the right way!
2. Groom the product backlog ahead of Sprint
The preparation for the next Sprint starts earlier than the actual start date.
Every Sprint planning must dedicate time for Product Backlog grooming, wherein the development team spends time creating, refining, estimating, and prioritizing product backlog items that can be taken in subsequent Sprints.
This effort is led by the Product owner with contributions from the stakeholders, Scrum Master, and the Development team.
This is an important activity that increases certainty for Sprint planning.
It gives a much better understanding of the work involved for each User story, and thus enables the team to do a better job of breaking down into tasks and estimating them.
Thus, this activity directly contributes to improving your Sprint velocity.
However, being not part of the current Sprint core-task list, under the pressure of time, it is easy to skip this activity. Do this at your own peril!
Kenneth Rubin, in his book ‘Essential Scrum’, suggests dedicating 10% of the available capacity of every Sprint to the Product Backlog grooming exercise.
3. Define ‘loadable’ Sprint capacity
The general tendency is to fill the cup to the brim, isn’t it?
For a Sprint of 2 weeks duration, a team of 6 people working 5-day weeks, will have 30 person-days of capacity.
How much of this would you fill up with task allocation during Sprint planning?
Many teams try to do the maximum possible—especially if they’ve transitioned from the traditional project management environment.
And that would be a huge mistake.
Consider the non-core-development effort and time needed for the team –
- Personal time off (planned vacation or emergencies)
- Non-Sprint commitments (support, maintenance)
- Working on other projects (bad practice!)
- Sprint activities: planning, review, retrospective, product backlog grooming
- Don’t forget the Sprint buffer (estimates are just that—estimates, not actuals)
Each of these requires dedicated time planned.
Typically, you would reserve 50%-60% of the Sprint capacity for the core Sprint work.
These 3 factors are typically underrated, unnoticed, or plain ignored on Sprint teams.
- Ensure everyone on the team understands DoR and DoD
- Groom the product backlog ahead of Sprint
- Define ‘loadable’ Sprint capacity
The teams that do not consider these will have a difficult time running Sprints effectively, with the following, but not limited to, problems –
- Out of control technical debt
- Bad quality deliverables
- Customer complaints
- Missed DoD tasks
- Team burn-out
- Lot of rework
- Quiet quits
Make sure you consider these factors, if not already, in your next Sprint.
Which practice would you recommend to run Sprints effectively?
Image courtesy cottonbro