This post is part of a series: Becoming Agile.
The Sprint is the core of Scrum. It's a finite block of time used for focused work with the goal to produce a potentially shippable product increment at the end of it. A Sprint starts with the Planning and ends with the Sprint Review and Retrospective. A very commonly choosen length for a Sprint are two weeks but it could be even less or more, though not more than four weeks. Sprints start immediately after each other and always with the same parameters.
At one of my previous jobs we used to joke when estimating contract work: I know what you're going to say! Two weeks? ... No, ten days!
It almost always resulted in "two weeks" or "ten days". Especially young colleagues came up with almost the same number of work days required for their estimations. The first wild guess was very often either two full weeks or the equivalent ten working days.
We had the theory, a timeframe of two working weeks is about the time you can easily comprehend and plan in your head. Everything beyond two weeks usually means, you need to put more effort in the estimation and get pen and paper to write down the different aspects and their estimated costs to reach a reasonable total estimation.
In my humble opinion, two weeks is the best length for a Sprint. It's long enough to get a reasonable amount of work done and it's short enough to keep up with the tasks.
Get a Goal
A Sprint without a goal bares the risk to fail. Without a clear target, it's hard to not loose sight of what is important and by that not finish all planned work. Furthermore, too many subsequent goal-less Sprints can be become frustrating for the team. Over time, the team might get the feeling of not generating any value.
A Goal gives the Sprint purpose: it's the most important requirement to be fulfilled. It can be the new feature you're working on, which will add the most value to the end user. It can be that the team supports another team reach their goal. Or anything else, that is clear enough to be used as a benchmark during the Sprint when decisions need to be taken on how to move on.
During the Sprint, the team can then easily check during the Daily Stand-Up whether they are still on track. A Sprint Goal helps to prioritize all the small questions coming up during the daily work:
- Is this performance optimization really needed?
- Do we need this fancy UI animation?
- Can we get this feature to work with a simpler solution?
When answering questions like those, a Sprint Goal can guide in to the right direction.
Finding a good Sprint Goal is sometimes hard -- if it is too hard, it might be a sign for that the team's job is not clear enough. Most of the time, though, defining the Goal is done quickly. And it may also be fun if you like: use movie references or titles for one or the other Sprint (try not to exaggerate, since this blurs the purpose of it).
If you buy something from the seller via the link above, I get a commission from your purchase. For you the price remains unchanged.