More Than Just ‘Passing’ the Sprint

When running a SCRUM process you will have a product backlog with a list of items. Each of theses items will be sized at a planning meeting before they are brought onto a sprint iteration. All pretty standard. The point I would like to talk about is the sizing. Sizing is for everything. The design, the coding, the testing and whatever else you have to do. This means if you do not test the code then that item is not completed.

The problem

A situation arose once where a bunch of code was written to satisfy a product backlog item but it arrived late on the last day of the sprint cycle, no manual testing was done. This was handled not by declaring the backlog item unfinished but by carrying the testing work through to the next sprint as a new item – so it appeared the item had been completed.

The problem with this is not that work was not completed, or that work was carried forward. This happens, it’s fine. The issue is firstly with calling untested work ‘done’ and secondly the de-coupling of the coding with the testing. By doing this you sacrifice collaboration between the developer and tester – this should not happen. Collaboration is key to agile.

What’s the motive?

In my opinion it’s down to the fear of ‘failing’. But what really fails? Ultimately, what we want to achieve is creating great software. Agile/SCRUM are enablers for this. ‘Failing’ a sprint iteration because some work is incomplete does  not mean you fail to create great software effectively. It just means this time round, things didn’t go perfectly (when does it?), and one feature will be slightly later than expected . By measuring the success of your software based on the number of times you get a green tick next to the sprint, you’re likely to fall into some traps. Like in this example where you have had to fudge the principles in order to get ‘results’. Ultimately here you’re sacrificing your software in order for the audits to read well. To me, that’s a huge loss of sight on what’s really important – The software being the best it can be.

The Solution

The SCRUM guide states:

“All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.”

So there’s your answer. It’s the same backlog item. You re-estimate it. If part of the work is done (yes, that means its tested), then it is likely to be smaller next time around.

To me the solution is to also not to get too hung up ‘passing’ a sprint. If you tinker with the results just to get a result in the now then you will most likely never get a good grasp on your team’s velocity and find yourself in the same situation many more times.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your 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 )

Connecting to %s