Definition of Done or How to really finish tasks?

Question

Sometimes it is hard to close a task. There might come a new information which demands an update of the task. The task remains a long time almost finished. New Versions and baselines allows us to close a milestone but allows thoughts like I fix this in the next release. I'm talking about the tasks staying at 90% in MS Project for much longer time than reaching those 90%.

Nevertheless, PM processes and tools usually demand a point in time when you say I'm done!, e.g. Scrum or EVM.

Fore sure, I know some theory: Tasks should be defined e.g. SMART, SCUM demands Definition of Done.

But how to handle this in real life, incl. documentation and team commitment, taking the usual shortages in time and budget into account?

Answer 1

You mention Definition of Done, and in Agile, the acceptance criteria and other user story content defines if work meets the user's needs, but often allows for shoddy workmanship. We all know we can cut corners to make things work in real-world environments. It's important to understand this has little, if anything, to do with the quality of the developer doing the work. I've seen so many great developers pressured into cutting corners in order to meet business pressures.

The Definition of Done is really about giving technical people leverage against business demands. The DoD allows you to establish technical standards (95% unit test coverage, automated acceptance tests, code review, applied OOD principles, etc). When you have a weak DoD often times work will get marked "done" and then you're off to the next thing, so you never get to go back to it until the problems are so significant that you have to go back and spend time refactoring or testing or debugging "off the books".

So, in summary, Acceptance Criteria verify that the application does what you need it to and a strong Definition of Done tells you that the work is complete, reliable, and maintainable. You need both of these to know that you can safely move on to the next thing without your project filling up with pools of technical debt.

Answer 2

When a task meets the acceptance criteria, that means it's done. No other options.

In real life, if a developed task meets the acceptance criteria but needs some more attention or some updates that means task is not defined well.

You may need to discuss this in retrospective meetings.

Possible challenges are as follows:

• Product ownership is ambiguous. If you don't have a dedicated Product Owner and tasks are defined by various parties like marketing, account management etc, therefore task definitions won't be clear and coherent. Therefore, you'll end up with done but uncompleted tasks. You'll need PO to consider all aspects of a feature.

• Existing Product-Owner may have difficulties in defining coherent tasks. Possible causes are inadequate product know-how, lack of information about the domain, lack of communication with related departments or users/clients or un-ability to make decisions on her own.

You need to discuss these issues in a well-attended meeting with all affected parties.

——

On the other you'll need a short-term solution also: If acceptance criteria is okay but the feature is not, mark as done but do not release it.

Ask product owner(s) to create a new story to complement/complete the previous one.

Never update a task if acceptance criteria is well done. It's simply breaking the sprint. So why so-scrum? :)

Answer 3

For us, "it depends". We try to take into account of whether this is, for want of a better description, "scope creep" and how much extra time it adds to the task.

We're using Scrum in 2 week iterations and if a request comes through that we think we can finish in this sprint without jeopardising our commitment we accept it. Sometimes we'll say "that makes this 5 an 8", but most times don't bother.

If it does impact our commitment, we talk through with the stakeholders on its importance and in most cases put it to the top of the backlog ready for next sprint. We explain to them the impact of replanning now and rejigging.

On those incredibly rare occassions it is a "we must have this, forget the other stuff", we will cancel the sprint and re-plan. This is very rare.

I find that once stakeholders realise there's going to be a shipable piece of software every iteration, the urgency turns out to be less severe than orginially stated.

This works for my current team, but may not work in your situation. Try it and review in the next retrospective.

Answer 4

I wonder if the issue is not so much closing off a task as poor estimation of how much work remains. It is pretty common in my experience to have progress stall at 90-95% complete.... mainly because of poor estimation both of what work needs done and poor estimation of resource availability.

A better practice for tracking progress is to define something as either complete (100% done) or not complete (0% done). For example, if you have some task that has five sub-tasks and only one of those five sub-tasks is complete then the task is 20% done. This should give you a less biased assessment of progress to date.

Answer 5

A few thoughts on the question:

In reality, I don't see the problem here. Frequent changes are absolutely normal for Agile. Even more, this is a part of Agile. You can't make part of product "at all". There is always a chance that there will be new requirements for this part. Second principle of agile is:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

So, if you already implement some feature, but Product Owner want to change or improve it, I don't see any problem for closing this task and adding new PBI to Product Backlog.

And, of course, Product Owner can't make global changes in functional requirements during Sprint. As SPDuFeu said, he can only cancel current Sprint, if he decide that current work of Developer Team is absolutely useless.

If you are worry about release plan...well, release plan is just a fiction in Agile. It is impossible to follow release plan if you have frequently changes.

Also, you said about "shortages in time and budget". I don't think, that Agile is good for fixed-price contracts. But in case you have budget/time limitation, you should avoid any changes in project.

Two words about my experience:

• It's a shame, but in the time when we worked with Scrum, we had no well defined DoD. Our main rule was: if all test cases passed, that means implemented feature is satisfy functional requirement. Approval from team's testers was enough for us. If after feature implementation our Product Owner wanted to change it, then (as I written before) he just add new item to Product Backlog. We improved some features several sprints after their implementation. It was no problem for us.

• Documentation. We tried to minimize it. The reason was that it's a pain to keep documentation up to date when requirements are change often. And of course "working software over comprehensive documentation".

• Team commitment, constraints of budget and time. I had one fix-price project (in truth two). Yes, we had strict limitations during these projects. But customer couldn't change already agreed SRS (in truth, he could, but it was additional pain and money for him and more time for us). And, obvious, our development process in that moment was not Scrum, but it had some of Scrum characteristics.

Answer 6

I'll speak from the Agile-Scrum perspective. First I need to break down your question into two different problem areas:

1) Definition of Done is an operating agreement on your team. Many teams do not task out their definition of done because it is redundant and not unique to any given user story. A definition of done defines the engineering practices and guidelines used to ensure the functional product is of high quality. When a team estimates a story they should consider the complexity of building a quality solution that incorporates their definition of done. Teams that don't meet their done criteria usually are not good at estimating accurately to leave enough space to build quality into the product. Definition of done usually touches on non-functional areas including:

• Unit Testing practices
• Automated Testing practices
• Manual Testing practices
• Performance/SLA requirements
• Security requirements
• Monitoring requirements
• Documentation standards

2) Finishing tasks doesn't always mean your team has met its definition of done. Don't fall into the trap of seeing a story with all completed tasks and thinking it is done or acceptable. Tasking is both a thought process and a documentation exercise. Highly disciplined teams continuously go through both parts of the tasking processes, most however document tasks up front and then let the actual thought process get out of sync with what was initially documented. "Working software over documentation."

Furthermore, done criteria are often subjective. For instance, ask a developer what "good" unit test coverage is and if 100% is reasonable for all stories. Or what makes a good automated test? What if it breaks during the next iteration?

So how do you handle this in real life. There is no silver bullet, but in Scrum you talk to your team every day about their stories to understand if the team is on track. Teams demo a functional story at the iteration end AND you ask to see things like code coverage, automated test pass rate, and documentation. You regularly talk to your team (during retro or ad-hoc) to understand if they understand the done criteria, see value in them, and if they feel they have enough time to build a quality product. Based on their continuous feedback you identify problem areas like estimation practices, technical gaps, etc and come up with plans to fill those gaps.

You mentioned taking time and budget into account. All done criteria are negotiable AND have an implied cost/benefit. Strong done criteria promote a sustainable product and negate certain risks throughout the life-cycle of your product.

Knowing what the product life-cycle will look like and which risks you cannot afford to take will help you understand where it is appropriate to adjust your done criteria.