March 18, 2015

SHOULD THE DEFECT BLOCK A STORY

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


Recent Articles

SAFE: Winning the Digital Transformation at the speed of startups and the scale of enterprise

June 20, 2019 | Kostiantyn Polosukhin, VP Strategic Accounts, IT Services Competence Platform, Account Management Director, CoreValue

Working with the Clients from various industries, we’ve observed certain challenges; a central item in their top list of business improvements. Is there a program, process or anything else that can make their organization work towards a better value that is delivered quickly, but aligned with all sections of the involved parts? Something, which would […]

Hot and Trendy: Google Teams up with Looker

June 10, 2019

The IT world is stirred up with the latest plans of Google to acquire Looker, a data analytics platform. Google LLC announced its agreement with Looker to join forces in the development of a comprehensive data analytics solution for customers.   Looker, a business analytics and data intelligence platform, empowers organizations to draw insights from […]

Contact Us

By submitting this form you acknowledge that you agreed to our Cookies and Privacy Policy.