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.

How to be good at planning poker and story points?

Story Points are easier to understand and work with than most people think.

What are story points?
A Story point is a arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story. In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort.

So teams size on a piece of work. Is it a lot of work? Is it complicated? Is there uncertainty?

    So three elements:

  1. Complexity
  2. Unknowns / uncertainty
  3. Effort

  1. T-Shirt sizing ( Large, Medium, Small)
  2. Story Points (modified Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100)

Get going
Scrum Master / Team Lead: During a session where the work is discussed, talk about a user story.


  1. Development team
  2. Product Owner
  3. Scrum Master
  4. Poker cards
  5. User stories / Stickies with stories

Ask the developers to think (NOT to talk) about how complicated it is for a moment. Bring in Scrum Poker cards or get a set of yellow stickies. And write per sticky the Fibonacci sequence (1,2,3,5,8,13). Or small pieces of paper will do too.

Ask the developers to select a card (picking a number) and hold it to themselves. Now when all the people have picked one, ask the developer to open their cards at the same time.


What if I am not in the same room (collocated)?
Ideally you are. But if you aren’t, or working remotely for the day; use an online tool, like made by Agile guru’s and free up-to 10 people.

Voting tricks
There’s some very interesting psychological trick behind the voting with closed cards. The surprise is great, instead of people influencing each other. Some people have bigger ego’s than the others. By not influencing each other the outliers who are more junior – for example – learn a lot from their peers because it always results in a conversation about the work; which evens out problems, reduces unknown elements of that work and so on.

Tricks from an Agile Coach
Some people will always try to quantify a point or a S/M/L size of a User Story into days, hours. People have learned for decades that when they hear the word Effort, that it relates to period of time (hours, man days, weeks). If that’s the case, try to forget the amount of effort you think it takes to finish the work. Instead ask the people to vote for just the complexity.

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.