March 18, 2015


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!



Recent Articles

Get 100% Code Coverage for Salesforce Custom Metadata Based Decisions

January 18, 2018 | Bohdan Dovhan

How to obtain a full coverage for code which uses Custom Metadata for strategy-like decision implementation? Introduction Many applications use configuration data. Configuration data might be relevant to the entire organization, or a subset of user, or even different for each user. For the purposes of this article, we will focus only on global configuration […]

Logging of Exceptions in Salesforce

January 11, 2018 | Mykola Senyk

Unpredicted behaviour in a custom code. Can we eliminate it? The ability to customize your Salesforce org code is not just a “nice to have.”  It greatly increases the capability and flexibility of Salesforce. However, custom code can also be tricky to use. It would be great if we could detect unpredicted behavior in our […]

© Copyright - CoreValue 2018
Salesforce, Sales Cloud, and others are trademarks of, inc., and are used here with permission.
Used with permission from Microsoft.