8 Main Reasons Why The Actual Sprint’s Progress Doesn’t Meet The Planning
Plan →Develop →Test →Deliver →Learn →Repeat is what we are doing as part of Hybrid SW and Algorithm project management. Here are several reasons which may affect a team’s progress during sprint, as well as tips on how to overcome them:
1. Team is not cross functional
In the past I have witnessed a case where we had to delay a SW version due to the absence of a specific developer. He was “the only one” that had the expertise in a specific sub-system in our SW code.
Years have passed, and together with the SW manger we are striving to cross-train each developer in order to have redundancy in the team’s capabilities- even if such training will impact our short-term deliveries.
Cross functional skills provide better value to teams as chances of innovation and creativity are higher among such groups.
2. Unclear or lacking Definition of Done (“Acceptance criteria in Jira”)
Same as in life, when it’s not clear where you’re heading to, you might find yourself in the wrong place…
Defining the Definition of Done of each feature serves as an official gate separating tasks from being “in progress” to “done”.
Usually, the responsibility of defining such criteria is in the scrum’s hands, while the Product Owner (PO) is accountable for it.
3. There is a technical debt that causes a lag in the development
It’s a never-ending war to reduce the size of technical debt in SW development.
One of our “tricks” is to automate some of the feature testing sequences.
Other way is to take the right buffer in each sprint in order to mitigate in case of urgent escalations.
4. Overworked team
The ground rule in sprint planning optimization is to make sure that your team is loaded with the exact amount of scope.
A good scrum master will know what the limit of each developer is, based on everyone’s capabilities, personal vacation days, etc. …
Usually, there is a personal backlog for each team member for cases when completes his tasks earlier than the sprint’s end.
5. Late integration
Late integration may occur due to a dependency in HW that is late or due to a delay in SW code readiness.
One of the basics of agile is to develop a lean code in order to reduce the time to integration and to minimize risks.
Two types of SW development:
a. Iterative development- adding mature building blocks along the development process.
b. Incremental development=Skeleton- building high-level program structures from start to end, then develop a robust content in it.
During the development process we keep adding content to each block.
*In both methods the development will be stopped once the acceptance criteria has met.
6. Feature estimation methodology
No one likes surprises and delays, especially a PO who manages several SW versions in parallel.
The accuracy of bug\feature estimation is crucial when planning a sprint.
While there are many Product owners who like to use a “finger in the wind” estimation, here are my top 3 favorites techniques:
a. History-based estimation- history and experience of the developer, experience with estimating similar tasks with similar complexity, past experience with the customer who will get this delivery and may or may not have feedback for the dev team.
b. Average of estimations- get estimations from all scrum members and do an average (or median) of all the results.
c. Weighted Three-point estimation-this method gives more weight to the most likely scenario while keeping in mind the edge cases:
while O- optimistic estimation, P- pessimistic and M- most likely.
7. Change of scope during sprint
One of my team’s KPIs is to focus on small amount of SW versions in parallel, while still supporting customer’s escalation.
Preparing with the right support buffer (#8 below) and keeping on regular alignment with the customer or customer’s representative (outbound product managers for example) will minimize the need for scope changes during the sprint.
8. Unexpected support from field\in-house
You can plan a pretty picnic but you can’t predict the weather…
Through the years we quantify the feelings into an amount of needed buffer. My team and I finally met the 90%+ planned Vs. actual in terms of field/in-house buffer planning.
We know that in sprints, where there may be risk to our deliveries, we should allocate additional resources to support. In other cases, when we deliver a small patch with an experienced on-site support, we feel free to reduce this buffer allocation from the planning.
Good luck! Please DM me in case of any questions.