What is a Development Sprint ?

From the atlassian website:

“A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work. Sprints are at the very heart of scrum and agile methodologies, and getting sprints right will help your agile team ship better software with fewer headaches.”

We’re not so sure about the fewer headaches. Sprints are an arbitrary unit of time - typically two weeks - in which a team plans and commits to completing a certain amount of work. This continual rolling jumping target enourages development teams to focus on delivery. Without sprints, the theory goes, there is no shared team target and “getting things done” will drift.

At the beginning of the sprint the team looks at the refined cards available to them and commits to completing a certain number of those cards in the sprint.

Very typically with sprints there are a number of set ceremonies:

• sprint planning
• retros
• measuring velocity

What are sprints good for ?

In our experience Sprints are a good way of introducing process to a team that has little or none. We’ve found them an effective in saying to a business “this what they’ll be doing for the next two weeks, unless there’s a fire, leave them alone to get on with it”. In return for that freedom the team has to own the work delivered understand why some things weren’t delivered and adjust.

In businesses that don’t understand how to manage the wip and frequently interrupt developers for favours or to change/add-to what they’re working on then sprints are a great first step to getting organised.

What are Sprints not so good for ?

Squeezing things into arbitary two week cycles is not particularly logical though in a healthy development team no single piece of work should be longer than a sprint. Our main issue with Sprints is that almosyt always go hand in hand with a heavy focus on velocity which is useful metric but only