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…
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.
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.
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…
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.