Restructuring your Sprint to Produce Finished Software

If your company is anything like many of the teams I’ve worked with your Sprints are a planning tool used to break down monolithic projects into smaller pieces to track progress.

In the real world big releases often pressure development teams to adopt more established project management techniques to hit deadlines. A PM will nominate a certain number of weeks for development (hopefully based on estimates your developers have provided) and then subsequent time for testing, bug fixing and UAT. The Development Manager will then allocate time into those Sprints.

But wait a minute? Doesn’t Scrum team us that we should be able to produce full working software at the end of each Sprint? If that’s the case then why are we saving all of our testing and bug fixing until the end!? It feels to me as though we’re running Sprints but ignoring the line of the Scrum book which talks about finishing a Sprint with deliverable software.

In Rolling Rocks Downhill Clarke Ching calls this GETS Software (Good Enough To Ship), it’s a term I like. In his book the team would build feature after feature however at the end of each iteration they ensured the product was GETS. That meant that if something took longer than expected or their budget was cut the team would always be able to fall back on the last version.

In a typical PM managed project I envisage features a development phase, when new bugs are carefully and painstakingly introduced. Then a testing and bug fixing phase, where they are removed.

waterfall_bug_flow

If however you commit less work to your Sprint, let’s say half the amount then your developer can spend the second week refining their work, working alongside the QA, designing upcoming features, and removing any bugs which are found.

This will obviously reduce your Sprint Velocity, however it will mean that whatever work is completed is completed, reasonably and as Clarke puts it GETS. However without the need for long and laborious bug fixing phases this time can often be reclaimed.

agile_bug_fixing

This approach is game changing for a number of reasons. Firstly your quality isn’t compromised, instead of a quality decline and then improvement your software stays at production quality. Second, should your customer, Product Owner, or business priorities change you can update your plans (maybe even delivering early). Surely that’s what we mean by Agile!?

Many thanks to FooPlot for the brilliant site I used to create these graphs and Jing for the screenshotting and labeling software.

3 thoughts on “Restructuring your Sprint to Produce Finished Software”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s