5

In a scrum project it is desirable to know what is your definition of done and what is your actual undone work.

Potentially Shippable = Definition of Done + Undone Work

http://less.works/less/framework/definition-of-done.html

A way to deal with this is to have a DoD with different levels, DoD for US, Sprint and Release.

For example, when you don't have the resources or the automation knowledge necessary to do a full regression tests per story/feature you should decide to do this once per sprint or even once before the release (even knowing this is risky).

My question is, how do you track in PBL this DoD tasks. A possibility: To have a simplified DoD to burndown stories even knowing they are not fully done. Then, To have another PBL from which the stories transition from Done to Done Done.

Related to this, is there a way to map this flow in Jira Agile?

Thank you.

Improve this question

2 Answers 2

Reset to default
3

The definition of done is used to determine which stories are completed within a sprint. If a story meets all the items on the definition of done then it is completed and counts towards velocity.

If you have a story that does not meet the definition of done it doesn't contribute to the teams velocity. If, for example, the team fails to get any story to the definition of done then their effective velocity would be zero.

The team should define a definition of done that is both effective and realistic. Creating a definition of done that cannot be achieved is pointless. It would never allow you to measure your velocity.

Why do we do this? We want to have a reliable measurement of progress. The Scrum framework says that the best way to measure progress is to measure items that are 'done'. If you have items that are partially done then it is very unclear what progress is.

As an example, imagine a story that the team completes, but doesn't do any regression testing on. The team gets to the last sprint and does a full regression test. They discover that in doing the story they broke lots of other functionality and it will takes days to fix.

This is why teams invest in automated regression tests. They know it is a large investement of time and resources. But they value the fact that they can be confident they have a potentially releasable increment at the end of each sprint.

Improve this answer
2

Definition of Done (DoD) is for user stories

In a scrum project it is desirable to have a DoD with different levels

No. In Scrum, Definition of Done (DoD) is for user stories only and it remains same for all user stories. When all stories of the sprint backlog cover the DoD then you have completed your sprint.

OK to have a 'less than ideal' DoD

An ideal DoD would contain everything that the team needs to perform in order to build a potentially shippable product every sprint. However based on the context, situation, and team's skills a subset can be chosen as initial DoD. Simplify your DoD to items which you can ensure for all user stories and stick to it. This would mean that at some point you'll have to work on the left out portion of the ideal DoD (this is mentioned as Undone Work in the article mentioned by OP). With the passage of time, you may add more items to your DoD list making it more closer to the ideal DoD.

Tracking Undone Work

Some teams make use of a Hardening Sprint or Release Sprint. Schedule a hardening sprint before doing a release, here you can have your Undone Work (tasks left out from the ideal DoD) which can now be tracked as a regular sprint backlog.

Make sure that a release sprint is not used to bucket all the remaining bugs and other stuff which should have been handled during regular sprints. In the words of Mike Cohn:

The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur.

Frequency of release sprints

As per Scaled Agile Framework:

Agile Teams can place hardening sprints anywhere, if and when, they are needed. So long as you are not “doing the stuff you should have done earlier,” and you are continually lightening the stuff in the “should be doing earlier” pile, then you are increasingly agile and on the right track.

Note: your idea of maintaining different DoD levels has been mentioned here: https://www.mountaingoatsoftware.com/blog/multiple-levels-of-done

Improve this answer
3
  • I have edited my question to better express what I meant with "desirable". I want to say it's necessary to know what is feasible to be in your DoD and what it is not. And track the Undone work.
    – ramon_salla
    Commented Oct 29, 2015 at 15:46
  • 1
    It doesn't remain the same for all stories. The article you reference (which, as a game developer, I feel is 100% is spot-on - context is everything) specifically says that you should varying DoDs based on need and value. In these situations, the value is building knowledge and not all knowledge benefits from one DoD such as release-ready.
    – Jeff Lindsey
    Commented Oct 29, 2015 at 17:15
  • @JeffLindsey I meant that in one sprint, all user stories should have the same DoD
    – Aziz Shaikh
    Commented Oct 30, 2015 at 5:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.