Is there Waterfall in your Sprint?

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:

  1. 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.
  2. 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.
  3. 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!

Rudra Mohanty

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.

Murray Robinson

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.

Good post to read

Anupama Kasturi

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 ...

Peter Merel

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/ ...

要查看或添加评论,请登录

Sanjay Kumar的更多文章

  • Why Agile? Why any process at all?

    Why Agile? Why any process at all?

    If you have worked as an Agile Coach, you must be familiar with resistance to Agile. It comes from various sources…

    4 条评论
  • Agile: You get what you wish for!

    Agile: You get what you wish for!

    With Agile adoption, organizations usually get what they wish for. But, do they get something meaningful and useful?…

    12 条评论
  • Essential Skills for a Scrum Master

    Essential Skills for a Scrum Master

    What skills should we look for while selecting/hiring a Scrum Master or Team Coach (a framework-agnostic term)?…

    20 条评论
  • Kanban Method: Basics and Beyond

    Kanban Method: Basics and Beyond

    This page contains a short list of articles and videos that will help you get a clear and deeper understanding of…

    17 条评论
  • 3 Most Common Challenges facing Scrum Teams

    3 Most Common Challenges facing Scrum Teams

    Scrum is a great framework. Its emphasis on collaboration and creating self-organizing teams is path-breaking.

    24 条评论
  • Top 10 Agile Coach Interview Questions

    Top 10 Agile Coach Interview Questions

    [Updated on Aug 16, 2019] The following (revised) list of top ten Agile Coach interview questions is based on my own…

    18 条评论
  • What makes a Great Scrum Master?

    What makes a Great Scrum Master?

    When an organization signs up for Agile transition using Scrum, one of the tough questions is who to pick as a Scrum…

    8 条评论
  • Scrum vs Kanban - Managing Change Effectively

    Scrum vs Kanban - Managing Change Effectively

    Imagine a common scenario - A new Agile team is following Scrum and is using 2-week Sprints. They start their Sprint on…

    16 条评论
  • Should we allow Changes within Sprint?

    Should we allow Changes within Sprint?

    In the Scrum world, it is one of the frequently asked questions..

    91 条评论
  • 5 Ways Management can Compromise Team’s Agility!

    5 Ways Management can Compromise Team’s Agility!

    Here is a common case – the management realizes the entire software industry is moving to Agile, and now even the…

    16 条评论

社区洞察

其他会员也浏览了