What do do when you don't meet the definition of 'Done'

Replies to This Discussion

Permalink Reply by Manish Manekar on March 13, 2010 at 8:21

Pat, to me this sounds like you have hit an impediment. So I will add to impediment backlog that will be worked upon in new Sprint. The story remains not done and I wouldn't carry it forward to the new Sprint backlog - assuming the firewall issue is being resolved by IT team. However, if the Scrum team is going to work on this issue and will spend significant amount of time in deployment, then split it accordingly (say 7 and 1 - 1 being deploying on one of the two networks) - based on the complexity of the deployment.

• ▶ Reply

Permalink Reply by shabbir on March 14, 2010 at 11:08

Hi Pat,

In addition to what you have described, I assume:
1 - Some of your team members will be working on this task to resolve the issue
2 - Team is continuing to do their next sprint.
3 - Business team is happy with the 'Done' on one of the network.

I would suggest to add it as a technical debt ( with high priority) to your next sprint and continue working on your next sprint and the technical debt.

I hope it helps.

Shabbir

• ▶ Reply

Permalink Reply by Robert Sfeir on March 14, 2010 at 15:03

Why would you do that? your work is done and verified done, the software tested and user stories implemented. You said your sprint is closed. The problem is an IT problem, not a software problem. I would close it and let it go.

• ▶ Reply

Permalink Reply by Ilja Preuß on March 15, 2010 at 9:27

Well, apparently, the work is *not* done, as their definition of done includes deployment.

Either there is a good reason for this - in which case it's the team's responsibility to get the story done. Pointing at others - "it's not our problem" - is a mindset that should be shun upon in a Scrum team.

Or deployment actually isn't necessary to get a story done. In which case this requirement should be removed from the definition of done.

• ▶ Reply

Permalink Reply by Ilja Preuß on March 15, 2010 at 9:28

BTW, I'm not sure what "the sprint is closed" exactly means, and how it could be used as an argument in either direction.

• ▶ Reply

Permalink Reply by Robert Sfeir on March 15, 2010 at 13:32

With all due respect, I never said point the finger at someone else. Perhaps I should have said it is a technical issue related to a firewall configuration and not a software/software deployment problem.

The first thing about Agile is to keep things simple. My response is in part to address a concern I have about the suggestions of taking on some kind of additional cost and moving user stories to another sprint when the impediment clearly has nothing to do with your SCRUM team. If you move the story to another sprint, you effectively change your velocity, sometimes that's what you need to do - not saying this is wrong, and in this case are you really changing your velocity appropriately? Say you move this user story to another sprint, the next sprint has 8 points you don't have to use against the total points in your sprint. However, those 8 points are actually complete (from a SCRUM team programming/testing point of view), the only difference is that the firewall is not working. Say it takes 20 minutes to fix the firewall; something your SCRUM team is not going to do. Now when you look at the complexity and cost of this issue, I am assuming 8 points is of higher complexity here (we use fibonacci numbers so 8 is on the mid-high level of complexity), you finish this issue 20 minutes into the sprint. What you've essentially done is finish 8 points much more quickly than you would another 8 point issue, with very little to no resources expensed. How is that OK? Do you then go back and find another story that would consume another 8 points and add it to the sprint since you clearly have room in your 4 week sprint? If so, does your velocity suddenly mean that instead of 40 points, you were able to do 48? Is that really accurate? You're certainly not going to change the number of points on the user story, I think that's worse and misleading.

The point I DO agree with is that the problem is the definition of done. If the IT folks are not part of the SCRUM team, as is usually the case - and am assuming that in this case based on the poster's description, then you're likely not including them into your Sprint planning. If that is the case, then definition of done should not include deployment to production. If the IT folks ARE part of the SCRUM team, then the story should not include IT deployment; you should really have split the story into implementation and deployment. In THAT case I would completely agree that you take the 'Deploy x story to production' and move it to a different sprint, or create a new user story which relates to fixing the firewall and assign that onto its own 1-week sprint for example, which may or may not include other stories to fill the number of points in your velocity (but you don't have to).

In our case we have Dev, QA, Stage and Production tiers. We do our own deployments to Dev and QA, IT does Stage and Production. Our definition of done is when we tag the sprint and push it to QA. Our 4-week iteration includes tagging to QA. Tagging to QA does not mean we will deploy to stage and production either. It just means we're done and if we want to we can. Yes there is a little overhead (though very little) in pushing to Stage and Production because someone has to communicate with IT, but really... are we interested in super fine grained point tracking here, and if so what's the benefit of being that fine grained? Kind of defeats the term and description of Agile if you ask me.

With much respect.
R

• ▶ Reply