Skip to main content

Definition of Done for Infrastructure Projects

Last post 01:37 am March 7, 2013 by Susanta Kar
3 replies
08:39 am February 26, 2013

Hi all

If any of you work as contractors, you may have noticed the recent increase in demand for agile consultancy in the infrastructure field. This typically covers such matters as technical support (first and second line), server administration, hardware and application software roll-outs, and upgrades.

This is quite different from the "classic" application of agile consultancy within IT, which has been more focused on software engineering. So although a successful agile transition is certainly possible within infrastructure, it brings its own challenges.

These include helping teams to elicit a meaningful Definition of Done. A coherent and practicable Definition of Done (DoD) is the key to stable agile delivery. A DoD presents the general* conditions of acceptability for a team's work. This is in contrast to the *specific* conditions of acceptability for particular user stories which are captured in the story's acceptance criteria.

In a software engineering context, a DoD might include criteria such as:

- Unit test coverage is at least 80%
- All unit tests pass
- At least one BDD test path is exercised
- All test cases are traceable to requirements
- Coding standards have been complied with
- All parameters and return types are documented
- All code and tests have been peer reviewed.

Has anyone ever tried to identify criteria which are suitable for (say) infrastructure deployment? As a starter for 10 this could *probably* include peer review and some level of documentation, and possibly security and failover considerations. Technical support, on the other hand, might have a DoD including lessons learned. Does anyone have any insights into this which are born of practical experience?


05:44 am February 27, 2013

This is a difficult one. Can we list down the a high level type of Infrastructure stories your team is going to implement and identify the general/common items which can be included in the DoD. After installation or upgrade of a software one of the item could be - the end user is able to login/logoff his system or he is able to restart and login into his system w/o any error. If you guys are using any ticketing system then the raised ticket has been closed.

Is it in compliance to organization security policy?
Has the asset tracker been updated, for any hardware request?
Has the new serial# been put on the new hardware?





05:30 am February 28, 2013

Hi Sanjay

Right now I'm transitioning an entire department of about 8 teams. Each team focuses on a specific area, such as Helpdesk, Server Infrastructure, Desktop Support, Device Deployment etc.

I suspect that each team will be quite unique in terms of its Definition of Done, and that I'll just have to make sure that each team elicits a DoD for themselves. Beyond that, I think it may be difficult to advise them. Agile transitioning in support and operations is less well understood than in engineering. The principles are clear, and hopefully in a few years some generally applicable patterns and practices will have emerged in the industry.


01:37 am March 7, 2013

My opinion is DoD will become check list/V&V process for each of the areas. Team should come up with their need - based on criticality & priority, we may have something like must-have and nice to have DoDs - others maintaining and executing that would be difficult. Moreover, we can have some weighted factors to determine whether DoD is achieved or not.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.