All About Agile | Agile Development Made Easy


Step 6: Sprint!

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.

Kelly.

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

See also:

How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat…

‘Implementing Scrum’ PowerPoint Presentation

10 Key Principles of Agile Software Development

Home



2 Responses to “Step 6: Sprint!”

  1. Artem Marchenko says:

    While I fully agree that the teams must be empowered, I also believe that in quite many organizational contexts teams just starting Scrum might not know what to do with this power.

    It is certainly a Scrum Master responsibility to help them learn. During the transitional it might be a good idea to tell the team what other teams find useful in the similar situations. Whenever people start something new, some amount of instructions in the beginning can be not just useful, but even welcome. Though it’s sometimes tough to include exactly as much recommendations as team is eager to take without feeling a command’n'controlled one.

  2. About pictures says:

    I think SCRUM is great in many ways and we can benefit from this management practise but there might also be some confusions and wrong assumptions about it.
    If I had to prepare a list, I would tell the list below. These are not true of course but people might be thinking or practising them.
    - SCRUM is an agile process for everything including engineering practises.
    - Having the product backlog is enough for development and requirement gathering is not something in SCRUM
    - Develop as much as possible; don’t need to leave much time for analysis
    - Writing test methods is very heavy and cannot be afforded to spend time for it
    - Develop first, change it later approach might start to happen
    - Giving exact estimates for tasks and not to rest the development team over the sprints or between the tasks.
    - Short SCRUM meetings are everyday but the teams might be missing longer meetings needed with more technical details
    - Unplanning becomes the agile process itself.
    - Estimates for a very similar task become different among the development teams

Leave a Reply

What is 7 + 1 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)