DevOps Zone is brought to you in partnership with:

I am a software engineer, database developer, web developer, social media user, programming geek, avid reader, sports fan, data geek, and statistics geek. I do not care if something is new and shiny. I want to know if it works, if it is better than what I use now, and whether it makes my job or my life easier. I am also the author of RegularGeek.com and Founder of YackTrack.com, a social media monitoring and tracking tool. Robert is a DZone MVB and is not an employee of DZone and has posted 95 posts at DZone. You can read more from them at their website. View Full User Profile

When Do You Say A Development Task Is Really Done?

07.23.2011
| 4564 views |
  • submit to reddit

I love when other people write a blog post at the same time you are struggling with the problem that they describe. Today’s timely post comes from Michael Bolton on his DevelopSense blog. In “The Undefinition of Done”, Michael talks about the fact that people typically have different definitions:

One issue, as I’ve pointed out before, is that people have preset notions about what “done” means to them. When I’m writing an article for publication, I put a bunch of effort into several drafts. When I’m finally happy with it, I declare that I’m done and submit it to the editors… Of course, I’m not really done. The article goes through a round of technical editing, and a round of copy editing. Inevitably, someone finds problems that have escaped my notice. They send the article back (typically when I’m busy with something else, but that’s hardly their fault). I fix the problems. And I submit the article for publication. Then I’m done. Done-done. The article is ready for publication.

In software development, “done” is definitely a confusing term. People looking at “done” from a testing perspective typically state that a feature is done when it has passed its tests. In the waterfall development process, a feature is only done when the entire project gets tested. That is not a useful definition because a waterfall project typically takes months to complete, without any feedback to the developers or the business owners.

In order to avoid the feedback problem in the waterfall process, people tend to move to agile processes. Many styles of agile have the concept of a sprint, a duration of time where development tasks are supposed to be completed. Let’s assume that you have sprints defined as having a two week duration. The goal of the development team is to create a list of tasks that they will complete within the two weeks. For that team, the definition of done is important. If the developer’s need to be “complete” within two weeks, a clear definition of done is needed. Developers tend to think of “done” as the time when the task has been fully developed and unit tested.

The problem with this definition of done is that the task is not really fully completed. If we follow Michael’s article example, the task will have some issues, defects that have to be corrected. When you think of it, done should mean that a task is fully developed, unit tested and passing QA.

One problem arises from this defect fixing process. Agile is dependent upon completed tasks in order to determine the team’s velocity, or the amount of work completed in the sprint. With defect fixing process delaying the “done” state, a task could have been started in one sprint and not completed until two sprints later. This can cause the team velocity to fluctuate heavily between sprints. Velocity is supposed to be used to determine how much work a team will complete in a sprint. I have seen some cases where the estimated work is based on the average of the velocity after the past two sprints. Other people have a more complicated process for estimating the work in a sprint.  In either case, the delay of completion can cause issues with planning work for the sprint. In order to keep things simpler, I have also seen the average velocity calculated over the entire project in order to take the fluctuations into consideration.

In reality, you just need your calculations to be consistent and everyone needs to agree to the same definition of done.

What do you do to deal with the varying definitions of done? How does this change your calculation of team velocity?

Enhanced by Zemanta
Follow the conversation at YackTrack!
References
Published at DZone with permission of Robert Diana, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Tomek Kaczanowski replied on Mon, 2011/07/25 - 6:04am

 

On the lowest level - that is on the development level - each team should probably come with its own definition of done. This is crucial if the team decides when the developed part (module, user story, feature - call it whatever you like) is ready to be marked of as "done".

See an example here: http://kaczanowscy.pl/tomek/2010-05/what-is-done  

 --   

Cheers,   

Tomek Kaczanowski  

 

 

 

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.