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

More Value with Lightning Value Providers

February 15, 2019 | Bohdan Dovhan, Senior Salesforce Engineer

Salesforce cloud platform offers the whole variety of customization options. Those include point-and-click tools like Lightning App Builder, Process Builder, Visual Flow and Workflow alongside development tools like Apex, Visualforce, Lightning Aura Components, Lightning Aura Events, Lightning Aura Tokens, Lightning Aura Standalone application and Lightning Web Components. Lightning Aura Components development involves the development of […]

Hot in Salesforce Marketing Cloud: January 2019 Release Notes

February 8, 2019 | Ihor Shupeniuk, Salesforce Engineer and Marketing Cloud Specialist

In the era of intelligent marketing with the proliferation of technology where modern consumers are offered the widest choice, Marketing Cloud is sometimes named a future-looking service, We continue to closely follow the developments and improvements to  Marketing Cloud and we can safely affirm that this product is becoming better and better. Everyone who has […]