2

Most of our Sprints are 2 weeks long, but occasionally, we want to meet a special deadline in less time (2-5 days). So, we do a special "short" Sprint that is a bit different from our normal routine.

Do you have any advice for these Sprints? Are they okay, or should we eliminate them somehow?

  • 1
    What type of special deadline are you meeting? Is it defect related? Do you derail a sprint in progress for this short sprint? – Jesse Nov 1 '11 at 16:11
8

First, you should understand what sprints are for. Sprints were introduced as one of methods which helps teams to limit amount of work being done in a specific time. In sprint we commit that we're going to finish a bunch of tasks in some time -- 2 weeks in your case.

However sprint isn't the only method of limiting work in progress. Another concept which deals with the same issue but differently are limits introduced by Kanban. In this case you just limit haw many tasks can be in progress in any given time and you don't introduce cadence for your production cycle.

In both cases the goal is to avoid big chunks of project being started and not completed, even though concepts are different.

Now, coming back to your question: there are teams which typically work with a week long sprints and they're perfectly fine. The style of work is pretty much the same as with 2 week long sprints. It does mean however that they're working on pretty small tasks as they're able to build, verify and deploy features in a week. From this perspective 5-day long sprint isn't that different -- if your tasks are small enough it may work.

On the other hand 2-day long sprint is a sort of extreme. I don't know any team that is doing such short sprints on a regular basis. My question would be: what is so important that you don't want to wait till the end of the week? Note: I consider a week long sprint as an alternative here.

If you just have to deliver under such short deadlines, e.g. you have SLAs or you focus on maintenance projects, that don't really suit your regular sprint schedule you may reconsider having sprints at all. Some elements of Kanban (limiting WIP, no time-boxing and visualization) can be a better approach in such situation.

A few things you may want to take into consideration:

  • How fluent the team is with the current process. The more smoothly things work, the less you should rush to introduce huge change.
  • How often there is a need to have this unusual sprint. If the anomaly happens every now and then you should think on rearranging your process. On the other hand if it happens twice a year you can probably live with it.
  • How much current process is adjusted to the specifics of work you do. For example, time-boxing-based approaches aren't the best tools if you deal with a lot of maintenance work.

Answering to these questions should help you to decide whether short sprints are the way to go or maybe you should reconsider using time-boxing.

And the last final advice: a bit of experimenting with your process is always a good thing.

  • I'm not really familiar with the ideas behind limiting WIP (Work In Progress)-- I'd appreciate more detail there. We certainly want to reduce having big chunks of project being started and not completed-- this has happened to us before. – Elliot Nov 27 '11 at 18:18
0

I would recommend you should keep them if they work for you. Why fix something that isn't broken?

Obviously measuring how much work you can take on is easier if all stories are of similar size and all sprints are of same length. However, in my experience shorter or longer sprints are not bad as such, even if you throw in a larger or a smaller sprint once in a while. Just make sure you always have a good reason for why you change something. I would recommend not to change for the sake of change.

You will also find that planning in particular for short sprints is easier if your stories are on the smaller end of the spectrum, e.g. a few hours and up to a day to complete.

0

I would recommend using Kanban for these short periods to avoid "destroying" your standard scrum setup. If your team has great success in your regular sprints butstart failing in these short sprints, they soon lose confidence in their regular sprints as well!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.