Three ways to handle bugs while on a DEATH MARCH loaded with technical debt?

A short consideration about the bugs in Agile (for Scrum teams): A team works together on a user story. And the definition of that being done includes that all development work is done and that all the issues or problems have been fixed before ending the sprint. However sometimes a user story can be interpreted in different ways. Or sometimes teams procrastinate in fixing bugs and bring in new work. They falsely consider the earlier work done. But there’s a big beast under water…

Situation: the product as shown is not good for the Product Owner

Possible causes:
1. The user story was not clear enough for the developer: The developer thinks he understands the story but the BA has a different idea about the same.
Solution: create a new story, add it to the backlog and prioritize it so that it comes in the next sprint (or in the same sprint in exceptional cases). The story should have its own title, description, acceptance criteria and should also be demoed – like all the stories.

2. The story is clear but a mistake is made and not seen by the developer or one of the peer developers (peer review is important).
Solution: Two options, create a bug and add it to top of the product backlog, raise it during the call, find a developer who is available to volunteer and implement the fix. Take it offline in a separate call. Or create a new user story instead. Which comes across nicer. It’s a fine line sometimes between: “YOU MESSED UP, I NEED A FIX NOW!” and “no worries mate, you can fix that later… whenever yeah”

3. The developer made the right code but broke another set of code
Solution: Make sure that continuously, in every sprint, a part of the bandwidth of work is allocated to regression testing. Developers checking whether the existing software, that was made earlier still functions. Make sure that you have this in place if you do not want to end up in a jungle of something called technical debt.

Another consideration
Some teams bulk up so many bugs, while they continue to produce new software. In all cases, me and my peers advise to stop pulling new work but fix the issues at hand first. This might sound simple, but if you have the drive of a deadline coming close it could feel like you should try and create more software first. Which means: you are on a death march.

Getting to a proper Definition of Ready (DoR)

During the refinement sessions we are preparing the place holder stories in the sprint backlog to get to this definition. Only if they are ready, we can bring them in to a new sprint.

User story has:

  • A description (As a X, I want Y, So that I Z).
  • Acceptance criteria (important for definition of done).
  • Story points.
  • How to demo.

So that’s equal for all the types of user stories, may it be a support task with uncertainties in terms of the actual work, or for JIT execution or any other possible work-related task.

Definition of Done (DoD) for a user story (feature)

This definition marks the point where a story is really Done. Now this seems like a cliché but there are many discussions on wether something is really done or not. In order to set the criteria for the DoD we use the acceptance criteria in the user story. This functions like a check-list; if all are checked the story is done.

And when all the user stories are conform the DoD we define the DoD for the sprint.