Does your team's burn-up chart follow Pareto principle (see picture above) - only a few stories (20-30%) get done in first 7-8 days and the rest (70-80% stories) are done in last 2-3 days?
If yes, there are good chances there is a waterfall in your Sprint - meaning the team is doing work in a phased manner. Here are some common side-effects:
- Inefficient resource utilization - testers lightly loaded in the first half and over-loaded in last 2-3 days.
- Stressful last few days - too much pending work
- Lack of predictability - High variance in velocity
- Accumulation of technical debt - the urgency in last few days leads to compromise with quality
What could be the reasons behind this waterfallish behaviour?
The most common reason for waterfall in Sprint is that each story is being developed by one single individual. This could happen for various reasons:
- Too many specialists in the team
- Team used to silo culture - coming straight from waterfall
- Distributed team members
So, what could be done about it?
Taking a reductionist approach, the key thing to focus on is to start 'finishing faster' so the team starts finishing stories as early as day 3 or day 4.
Here is one way to do that: aim to finish each story within 50-60% of the sprint length. So, if your sprint length is 2 weeks or ten days, try to finish each individual story within 5-6 days of starting work on it. And, if your sprint is 3 weeks, no story should take more than 7-8 days. Of course, some stories can be done sooner.
That being the focus statement, what specific actions would help team achieve that? Ideally, the coach/scrum master needs to have a discussion with the team how they could achieve that - primarily to make it a team's decision and to improve their commitment for the chosen actions.
Below are some ideas you may use to fuel the discussion with the team:
- Break down user stories to smaller size: Be careful to use vertical slicing rather than horizontal slicing. In short, each story must be independently testable.
- Encourage collaboration on a single story: When two or more developers work on a single story, it not only gets done faster but also results in better code quality and improves team collaboration. If you see resistance from the team, try to soft-sell the idea of collaboration for big stories in the beginning. Once the team members get used to collaboration and witness the benefits, it will be natural for them to try it for all stories.
- Increase sprint length: This should be used as a temporary measure or if the other measures fail to reduce cycle time of stories. And, if you choose this, remember to come back and challenge your decision on sprint length once the team has gained a better rhythm.
And, if all fails, consider the option of using continuous flow of Kanban Method. And, if you do, please make sure you understand and use Kanban metrics (CFD, Control Chart and Lead Time Distribution) to ensure better predictability of work completion.
Thanks for taking time to visit this page. Request you to share your thoughts and your personal experience on what has worked for you in establishing a smoother, more predictable rhythm of finishing work items during sprint.
[This article was first posted on LinkedIn. Please find the original post here.]
