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:

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 8 + 1 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”

PETER SILVA-JANKOWSKI
IPC MEDIA

“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”

LUKE SHARKEY /STRATEGY & IMPLEMENTATION LEADER
SUNCORP

“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”

GILES BENTLEY, DEVELOPMENT & OPERATIONS DIRECTOR
TIME INC

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA

“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”

GINA MILLARD
GLASS'S INFORMATION SERVICES

“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”

ANDY JEFFRIES/TECHNICAL LEAD
IPC MEDIA

“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”

HANNAH JOYCE
GLASS'S INFORMATION SERVICES

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”

BRUCE WEIR/EGM
SUNCORP

“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”

BEATRIZ MONTOYA/CONSUMER MARKETING DIRECTOR
IPC MEDIA

“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”

PETER THATCHER, SENIOR ACCOUNT DIRECTOR
ThoughtWorks

“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”

JULIE PEEL
GLASS'S INFORMATION SERVICES