So you’ve got your backlog in order, estimated your backlog, clarified your requirements, planned your sprint and created a collaborative workspace. Now you’re ready for Step #6 – Sprint!

Scrum does not really prescribe how you should go about delivering the tasks in your Sprint. Scrum is an agile management practice and doesn’t really cover agile engineering. XP (Extreme Programming) on the other hand is an agile engineering practice.

Personally I think this is the beauty of Scrum.

Whatever engineering practices you use, from cowboy to rigorous, from RAD to RUP, from XP to DIY, whatever, Scrum can be laid straight over the top. That’s why I say it’s easy. It’s an alternative management approach. For projects and for BAU (Business As Usual). It’s not a development approach. And that’s why Scrum works, even outside a development context.

So, the team Sprints to achieve the Sprint Goal they committed to during the planning stages (steps 2, 3 and 4 of this series). Although Scrum does not prescribe anything much about how the team should do this, there are a few key principles of agile software developmentI want to highlight that are particularly important to remember at this stage of the Scrum lifecycle…

Agile teams must be empowered

The Scrum team makes its own decisions during the Sprint. The team is empowered. Every time a manager steps in and makes a decision for the team, they remove some responsibility from the team. If a manager keeps doing this, the team gradually – piece by piece – loses ownership, along with their commitment.

As a manager, the team must be given support, guidance, coaching and assistance. Not instructions. If necessary, the team should be helped to reach its own decisions. Facilitation becomes a key skill for agile managers. Using their experience and management responsibility to help the team do its job. Not to do the team’s job for them. Agile management requires servant leadership. Ideally inspirational leadership. The team self-organises to achieve its goals. But self-organisation is not boundaryless.

Time waits for no man!

The timeframe – in this case the Sprint Duration – is fixed. You can add scope if you absolutely must, or add tasks if you discover they are needed. However changes in scope should be offset by compensating reductions in scope, i.e. removing something else from the Sprint.

If you finish early, include more scope, i.e. the next most important thing on the Product Backlog. If you look like you’re going to finish late, you must reduce scope in order to hit the deadline.

done means Done!

In order to achieve a fixed timescale, it’s imperative to make sure you complete one feature at a time before moving on to the next. You need to avoid reaching the end of the Sprint Duration with 90% of everything. 90% of everything allows you to deliver nothing. It’s better to have 100% of something…

Testing is integrated throughout the lifecycle

Achieving completeness – to make sure something is really done before moving on – means testing must be integrated throughout the lifecycle. In agile development, whether using Scrum or not, the traditional development lifecycle of analyse, design, develop, test, is repeated on a feature by feature basis, rather than in big phases for the entire project or product.

Testing starts at the start of the Sprint. In fact, it starts earlier than that. It starts in Sprint Planning, as involving testers at the start helps to clarify requirements. Writing the tests before a feature is built, means developers have more of a tendency to build the code to pass. Test driven development starts here.

No interference please

Ideally, once a Scrum team has committed to a Sprint, they should be left to focus on delivering what they’ve committed to. Constant changes to priorities prevent a development team from being fully productive and in the worst case can prevent a development team from delivering at all.

If priorities must be changed during a Sprint, then so be it. However an equivalent piece of work must be removed from the Sprint to compensate.

Personally I like to educate Product Owners about the impact of chopping and changing by calculating changes at double the effort. This is because the new piece of work was not discussed in Sprint Planning etc, and therefore all this has to be done in addition to the effort to implement the change. Doing this mid way through the Sprint is very disruptive. So, if you must add 3 hours of development, you should take 6 hours out.

Aborting a Sprint

Aborting a Sprint is a very serious act and should be reserved for exceptionally rare circumstances.

Let’s say the Sprint Goal is no longer applicable. Or something has come in that means we really need to re-focus the team completely. Or the Sprint or project is so far off track it really warrants a complete re-think. These are the kinds of events when you should consider aborting a Sprint.

Aborting the Sprint means literally abandoning it and going back to Sprint Planning to re-assess priorities and re-plan.

Hopefully this situation is very rare, and ordinarily your Scrum team Sprints successfully to achieve the Sprint Goal.


Next, Step #7: Stand up and be counted!

See also:

Share on facebook
Share on twitter
Share on linkedin

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

In The Zone with Marcin Zasepa

Welcome to the second in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Marcin Zasepa, CTO at Homegate AG in Switzerland. Every episode will be approximately 30 minutes

Read More »

In The Zone with Sasha Bilton

Welcome to the first in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Sasha Bilton. Every episode will be approximately 30 minutes long, and we aim

Read More »

Case Study: DAZN Data Engineering

Find out how 101 Ways helped DAZN improve their existing data warehouse as well as planning and setting the foundations of the new cloud-based data platform. Click here to download the full case study. Get in touch with a member of the 101 Ways team if you would like to discuss ways in which we can help you and your company

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?


101 Ways Limited
41 Corsham Street
N1 6DR
United Kingdom


101 Ways Limited
No.1 Spinningfields
Quay Street
M3 3JE
United Kingdom


101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at