Blog

SHOULD THE DEFECT BLOCK A STORY

March 18, 2015

Hello.

This blog post is inspired by many projects I was working on and which had issues with progress visibility because of user stories blocked by defects till the end of sprint and, as a result moved to next sprints.

This situation is common as a SCRUM says that the Sprint velocity is equal to the number of story points of the user stories that were “done” during the Sprint.

Usual SCRUM process has only three user story states:
To Do, In Progress, Done.

Sometimes this may be extended to more columns and some (or most) of the projects I’m conducting at the moment have around seven or eight different states, where two of them are To-Do and Done and five or six are interim “In Progress” sub-states.
But we still have only three states.

Simple? No.

The user story is done only when it fully satisfies the “definition of done” – some list of criteria that were defined as generic criteria for any work done on the project plus specific criteria related to the specific user story: what story should actually do so it can be considered as done.

And sometimes the definition of done may include for some reason something like “No known defects”. Or something similar.
This is a bad practice.

Definitely, this is bad when the defects are found.
But the defects are the part of our everyday routine. There’s no code that doesn’t have defects.
There’s a bad code that has a lot of defects, there’s a good code that has very few defects, but the code always has defects, period.

Having “No known defects” in definition of done means that you will need to fix everything before the story may be marked as done.
Definitely, there’re some defects that are story blockers – wrong calculation, wrong behavior, non-coverage of the definition.

However, if the story works as defined – it is done.
And if there’re defects – we will manage them.
If there’re “clarifications” that occur only at the stage of reviewing of the story implementation – we will manage that.
If there’re some additional items that are related to the story, but were not well-thought during a story definition and clarification beforeimplementation – we will manage that as well.

But, the story is done.

There should be no practice to keep a story in progress until all known defects or improvements to the story are fixed.

Avoid “preliminary perfection”, avoid extension of the story definition after it was completed, avoid unnecessary refinement if it was not done during the story acceptance criteria defining stage.

And be happy!

Tags



Share


0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Articles

Part 2: Optimizing and scaling microservices. Organic growth of eco-systems.

October 11, 2017 | Nikola Krastev

A microservices approach is not a silver bullet for all software architecture problems. It introduces tradeoffs and challenges of its own. However, process gains and improvements in human performance have been considered to be worth the overhead in technology. Here are some general arguments against using sophisticated SOA. Server performance and overhead in communication By […]

CoreValue President at IT Arena 2017

September 27, 2017

We are pleased to announce that CoreValue president Igor Kruglyak will participate in IT Arena 2017, to be held in Lviv, Ukraine, September 29 – October 1, 2017.