Ramsay Ashby

Software Engineer specialising in agile practices & automated system level testing. I am a PSM III certified Scrum Master who is passionate about helping teams deliver valuable software, faster.

Scotland, United Kingdom 36 posts

How long should your Sprint be?

When my friends or new colleagues ask what my job entails, I usually explain that I help teams to perform at their best by helping them streamline their processes and ways of working.

What I neglect to tell them is that a substantial part of my career to date has revolved around protecting a team's right to choose their Sprint length. I've lost count of the number of discussions, debates and dare I say arguments that I have been involved in over whether teams should be forced work to a particular cadence, usually one week.

The logic behind one-week Sprints usually revolves around a few assumptions:

  • If Sprints are good, more Sprints must be better
  • Shorter planning cycles must be better than longer ones
  • Teams can plan a shorter period easier than a longer one
  • If something unexpected happens, like an incident in production or a requirement from another team, the team can act on it sooner.

Before going further, let's address that last one because it is a bit separate to the others. As long as they are not endangering their Sprint Goal, a team is always free to adjust their Sprint Backlog. There is no issue with them reacting to issues in production or for another team. If such work would endanger their Sprint goal, then that's invaluable transparency that potentially warrants and adaption to the process

A few years ago I blogged about the purpose of a Sprint.

In Scrum, the Sprint serves many purposes. Above all though, it’s a time box within which the team can creatively and ingeniously craft solutions to complex problems. It gives the team an uninterrupted period to ‘get their heads down’ and work together to build something awesome, and it gives the business a commitment that within a certain period their agreed goal will have been met.

When I talk to teams about their Sprint Length, one of the key criteria that I need to understand is how long it typically takes them to solve a [meaningful] complex problem. I frame everything around this, because if the team is not using the time-box to solve such a problem then the value that Scrum is likely to bring the team -- and business -- is easily diminished.

If the Sprint length is notably longer than the time that it actually takes to solve the problem, then the time-box doesn't offer as powerful risk control as it otherwise could, and the team is potentially missing opportunities to adapt their approach.

If the Sprint length is shorter than it takes to solve a meaningful problem, it ends up taking multiple Sprints to solve the problem. Within this, there tends to be two failure modes:

1) The team allows tasks to roll over the Sprint boundary, and typically the notion of a Sprint provides no real benefit. I've previously described this as 'continuous chunky vomit'; Value does come through eventually, but it isn't pretty.

2) The team excessively plan up front to ensure that each Sprint they still achieve a goal. But that goal is typically devoid of any meaningful value to the customer, the business, or the team itself.

Whilst neither failure mode is good, the second one is far worse because it eradicates transparency and moves a team's focus from 'satisfying the customer through early and continuous delivery of valuable software', toward simply delivering 'something'.

There are warning signs of a team falling into this trap:

  • They 'spike' almost everything because they are afraid of uncertainty and are afraid of taking risks, so they never dare venture into the unknown. This means that almost everything takes at least two Sprints (one Sprint for the spike, and one Sprint for the work).
  • Everything has to be planned carefully. Look out for Sprints where the goal is creating a detailed plan of how the work will be carried out. This could be in the form of a technical architecture, or simply a large backlog of 'tickets' on the Product Backlog that don't change.
  • It is tricky to identify the start and end points for a notable piece of work, like a new feature or service.

But why is this really a problem?

Empirical process control can only work when one can inspect the genuine delivery of actual valuable working product. If a team is unable to deliver product value, then what are they able to inspect? Of course, said value can be small, but it has to exist and be meaningful. A thin-slice that brings no value to anyone cannot be declared good enough.

If teams are framing their work around meaningful problems, then it is infinitely easier to inspect and adapt everything, because the entire process, the tools, the people and their ambitions are framed around something that tangibly matters for the customer, and by extension the business. If the team's work is framed in almost any other way then they are essentially surrounded by fog, guided by their best-guess plan and an unhealthy amount of blind faith that if they keep heading in down this path that, eventually, their destination will emerge.

If a team can typically solve a meaningful problem in a week then that's probably how long their Sprint should be. If it takes them two weeks, then their Sprint should be a couple of weeks long. Nobody understands the work that is required more than the team itself, and although they may need some help and support from somebody like a Scrum Master, their judgement and opinion is what matters.

The other angle that mustn't be forgotten is that the Sprint is the container for teams to creatively solve a complex problem. A complex problem by definition will have unknowns, and unknown-unknowns. The team needs to have space and capacity to explore the problem space and try out different approaches. They need to expect some ideas not to work, or to be harder than they first expected, and have time to either change their approach or simply persevere.

Lean startup encourages teams to 'fail fast' and learn as quickly as possible, and for teams to be able to do that but still uphold a meaningful commitment, they need to have enough time and enough flexibility of scope in their Sprint.

Changing your neighbour’s lightbulb

The other day, I had to change the lightbulb in my kitchen. It took me just a few minutes from spotting the problem to having it fixed.

I know that my neighbour’s house has the same light fitting. If they asked me to help them change the bulb in their kitchen, it would take me just a few minutes to locate a new bulb, remove the blown one, and fit the new one.

But if I wanted to change it myself, without their request for help, or without their permission then it becomes a lot harder; breaking in to their house to do so could well land me in prison.

Sometimes we have all of the knowledge, skills, and tools that are necessary to solve a problem, but we are unable to do so because of organisational or societal boundaries. Even the simplest things can become unsolvable.

Businesses and teams need to structure themselves such that nobody feels that they have to break the rules to help.

Our teams shouldn’t be locked down like our houses are.

When is a Sprint a success?

Let me cut to the chase and offer the following as a definition of a successful Sprint:

A successful Sprint is one where an increment of significant customer/user value has been sustainably delivered in broad alignment with what the team had forecast that they would deliver. As a consequence of their work they now have a better understanding of their problem-domain, and of their next steps. Additionally, the team have agreed what they will do differently (improve) to try and increase the likelihood of success in their subsequent Sprint(s).

Success criteria for a Sprint is something that I have discussed more times that I can keep track of. From interns and graduates fresh out of university to seasoned C-level managers, everybody seems to have their own idea of what 'success' looks like in Scrum.

Probably the most commonly cited definition is that 'every card brought into the Sprint in Sprint Planning is done'. I think that this viewpoint revolves around the common misunderstanding that the Sprint Backlog is a task list, and therefore the definition of success is coupled to that list being completed.

That's a kinda scary definition, because it inverts the first principle of agile software development by suggesting that following a plan is the most important thing.

Another common angle is that 'success' means that the Sprint Goal is done. I greatly prefer this over the previous definition; a well crafted Sprint Goal ensures that there is flexibility in scope, but also provides a 'guarantee' that value in being delivered to the user/customer. If a team is achieving this every Sprint, that is a typically a pretty good sign for the health of the team, and the project. But it is definitely not the only sign of success.

For example, imagine a team that takes on a hugely complicated/complex Sprint Goal, and delivers all bar one very small part of it. Perhaps it is a global product and they managed to release an industry-changing new feature in all bar the smallest of their supported markets. This is probably still a triumphant victory for not just the team but their wider business. If they had taken on a smaller goal which they did get completely 'done' but made no material difference to the business or industry, would that have been more successful? I think that we'd all agree not.

The purpose of a Sprint is to give teams a chance to creatively solve complex problems. It's an empirical process which means it all revolves around inspection and adaption.

This starts to highlight the problem with having black and white 'success' criteria. In a complex domain, we cannot [reliably] predict the relationship between cause and effect. In other words, we can't know before we start exactly how things will unfold. It's like trying to define success for each and every child, before they are even born.

Our definition of success really needs to acknowledge the uncertainty that has brought us towards an empirical agile process, rather than a tightly defined (more waterfall) one. This takes us to where we started this post, with a definition of success which can be applied uniformly and crucially explained to key stakeholders like management.

Your Sprint Goal still matters, but I think it is for the team to define and understand exactly what it means to them. The Scrum Guide says it "…is an objective set for the Sprint that… provides guidance to the Development Team on why it is building the Increment", and I think that is a pretty good starting point.

If you've got a different (or more concise) definition of success, please comment below.