Is there Waterfall in your Sprint?
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.
Cheers!
Delivery Manager | Agile Coach | Digital Transformation | ServiceNow | ITSM | ITOM | ITAM | Agile | Scrum | SAFe SA | Telecom | OSS | Assurance | Customer Expectation Mgmt |
6 年Thanks Sanjay, Very good & pragmatic approach. Time to explore it in my project.
A No-Nonsense Leader transforming corporate strategy into practical results
6 年I have tried all the methods you suggest to resolve this problem and while it helps it doesn't solve the end of sprint crunch. After trying Kanban I realised that the end of sprint crunch is caused by starting a batch of new stories at once at the start of a sprint and trying to complete all the planned stories by the end of the sprint. As soon as you move to Kanban you get a much smoother flow of work which removes these bottlenecks. End of sprint crunches are one of the main weaknesses of scrum as a methodology.
Agile Coach
6 年Good post to read
Consultant - Enterprise Agility at Tata Consultancy Services
7 年Nice post !! Most commonly occuring pattern ..and yes this is mini waterfall within a sprint !! It takes time to get out of this .. u have given some simple practical approaches ...
Founder XSCALE Alliance. Author "the agile way".
7 年Nice post! See also the related but longer term anti-pattern at https://www.dhirubhai.net/pulse/disrupting-agile-industrial-complex-part-eight-change-peter-merel/ ...