Shrink or Grow Sprint Length

Why teams should not shrink or grow sprint length

Sprint length to shrink or grow. Jen, one of the Scrum Master I am coaching and mentoring asked recently:

I am scrum master for this team and generally, we do two-week sprints. But, for this sprint the team does not have enough work, so they want to shorten the sprint from two weeks to one week. Can I allow them to do that?

Grow Sprint Length

Now, let’s ponder on this question. Take a minute and think about it. What would be your answer? Why? 

To answer her original question, I said a big resounding NO! In bold capital letters!

Value of regular Heartbeats

There are many reasons for not allowing the Sprint to shrink or grow. We want the team to pick a sprint length and stick to it, no matter what. Instead of focusing on why we do not allow it to shrink or grow, let’s focus on the positives. Let’s review the reasons and value of staying on the same length. Keeping the sprint length same provides:

  • Consistency and a Rhythm for the team
  • Repeatable and Predictable Cadence
  • Consistent length provides valuable data that can be used for forecasting
  • Schedules that are known well in advance, and can be put onto calendar to help block time on key players calendar
  • Valuable data they can help team in deciding how much or how little work to take into next sprint

Don’t flush them down the toilet

There are several measurements that are linked to sprint length. Measurements such as:

  • Velocity
  • Say: do
  • Story burn-up
  • Release burn-up
  • Feature burn-up

You allow your sprint to shrink (or grow) and you are invalidating all the data, you are essentially flushing all these down the toilet!

Use it Wisely

If you have a situation where the team does not have enough work for the next sprint, it might be an indicator of the team not doing backlog grooming; or at a minimum, it is an indicator that the backlog grooming is not done properly.

In a scenario where the team has spare capacity, instead of shrinking the sprint length, the team could do other, very useful activities. They could use that extra time on:

  • Refactoring the code
  • Learning new stuff
  • Cross training within the team
  • Automation
  • Spike or research on the next priority features functionality
  • Experimentation

Sprint’s are fixed length. Scrum does not allow them to shrink or grow. Once the team agrees to a specific length, they have to, rather, they need to stick to it. Fixed length eventually will enable them to settle on a rhythm giving them even heartbeats!

mentorME

We offer mentoring and coaching to up and coming Agilists; often time doing 1:1 coaching. If you want to grow in the agile space, if you want to expand your horizon, if you want to learn the tools and tricks, sign up for mentorME.


Got more questions? Please get in touch with us here.

The “No” Repertoire for Scrum Teams

Learn to say 'No' to get more Done!

In the book, Essentialism: The Disciplined Pursuit of Less by Greg McKeown,  author talks about the importance of saying ‘No’ to focus on and completing what is important and essential right now. Get Hyper Tip

In Scrum, you go into a Sprint having already made a commitment to a number of stories. What happens when your manager, supervisor, or one of the stakeholders comes to you requesting to take on one new thing on your plate. Are you a people pleaser? Do you say ‘Yes’?

If you said ‘Yes’, you already undermined the commitment the Team made to the sprint. A better approach would be to say ‘No’. But, how do you say ‘No’ to your manager, supervisor, or the stakeholder (who might be paying the bills)?

The “No” Repertoire

In the book, Greg suggests having a ‘No’ repertoire handy. You can get to this list when faced with a situation where you have to say ‘No’, and say it gracefully. Here is my version of the ‘No’ repertoire for Scrum teams.

  • No. We can not take on this new Story as we are already ‘in flight’ into a new Sprint.
  • Yes, we may be able to take on this new Story. But, what are you willing to de-prioritize from our current Sprint?
  • Thanks for this new Story. We can put it on our Product Backlog, and take it on in the next Sprint if it is still your Priority.
  • We can take on this new Story, but are you willing to put the success of the current Sprint on the line for this new Story?
  • Can you please explain the business reasons behind this urgency (on this new Story)?
  • Why can’t this new Story wait till we get into next Sprint?

[bctt tweet=”The “No” Repertoire for #Scrum Teams! http://www.nimeshsoni.com/get-hyper-tip-learn-to-say-no/ #getHyper #Agile”]

Yes, you can say ‘No’ to your stakeholders. You just have to learn the art of saying ‘No’ gracefully!