The budget is limited, the timeframe is short, the requirements change a lot, the stakeholders do not know what they really want…if this is the nightmare you have on your hands, consider using an Agile project framework. It may be the polar star to follow, a perfect solution to run projects nowadays.

Unfortunately, as usual, there’s a tiny detail that may be waste everything out and ruin your project success.

Definition of “Done” is unclear… (Keep reading if you are curious to know more about this)

An Agile project has defined phases (sprint planning, sprint retrospective, etc.) and metrics (sprint and release burndown charts) designed to ensure that the project runs smoothly without relevant issues.

As far as my experience, most Agile projects fail even after following all the phases perfectly.
One of the main reasons is that the Agile team (product owner primarily) is not able to deliver value as planned to customers at the end of each single sprint. [It seems likely that the product is not fully tested, partially refactored (when extremely lucky) and it is not ready for release at all.]

A clear and shared “definition of done” may seem a small piece of the puzzle, but it may represent the most significant barriers to the success of a project. Without a consistent meaning of “done”, project speed cannot be estimated and progress cannot be monitored as well.

Instead, a common “definition of done” guarantees that the increment in the product produced at the end of each sprint is of high quality, with minimal defects.
That’s why I truly believe that “definition of done” is the Holy Grail of Agile.

Now, we agree that the “definition of done” cannot depend on a single driver, but it is the disposition of different dots that linked by a line represent the figure we are looking for. Based on the time at disposal and on the customer agreement to spend time in test automation, I want to show you what I consider two different approaches to get a kind of “definition of done”.

A straight and time-limited approach

Below what I consider the minimal set of activities to get a kind of “definition of done”:

1. Identify user stories

The first and the most important activity is probably a clear definition of the user stories. I want to point out that I’m woking in consulting and Agile projects are carried on with the customer. It means the product owner is usually a customer employee that should have a 360° knowledge of the whole domain and he should bridge the gap between IT and business. Unfortunately, it is not simple as expected and the user stories tend to bee too generic and difficult to evaluate. It is probably one of the most difficult tasks to define complete and concise user stories, but you should do your best to do it since it will extremely ease your work in the future.

2. Sub-tasks identification

Once you have clearly defined your user stories you have to identify technical tasks. They should be as more detailed and atomic as possible in order  to do better estimations.

3. Sprint definition and Backlog refinement

Put user stories with high priority and with a clear definition in the firsts sprint and put the others in the backlog in order to be analyzed in the later sprint planning.

4. Set-up environment

Development, test and production environment must be configured as needed. Continuous integration framework and environment management should be put in place.

5. Prepare unit test cases

Unit test cases are essentials to test your code. I suggest to write them before coding, adopting a TDD approach. Test automation is a plus.

6. Code!!!

Take time to transform your user stories in a product!!!

7. Execute unit tests

Unit test cases have been executed and are working successfully.

8. Do regression tests

Run regression tests to ensure that defects have not been introduced in the unchanged area of the software.

9. Pass user acceptance tests

Each finished user story has passed through UAT (User Acceptance Testing) and signed off as meeting requirements. In Agile UAT can be done during the Sprint Review.

10. Prepare and share project metrics

Update burndown chart regularly and send updates to stakeholders for alignment. It is essential to have a shared and approved “definition of done”

11. Prepare the build

Prepare the build (successful). Generate change log report from code library and create deployment guide.

12. Close the Sprint

Close the project marking as complete all finished user stories/tasks. Complete anything specific to your project environment.

A complete approach

In addition to the previous activities, a complete approach should take into account the following ones. Of course, you need to spend more time at the beginning but you will have benefits at the later time.

1. Make documentation

Prepare documents to support the sprint demo and create test data to support test execution.

2. Refactor source code

The source code needs to be refactored to make it comprehensive, maintainable and, amenable to change. A common mistake is not to maintain refactoring in the “definition of done”. The refactoring process normally spills out to next sprint or, worse, is completely ignored.

3. Code review

Code review expects a person from your team commits to reviewing the code that has been pushed into the repository. Of course, it takes time and, even if it should be considered necessary, you can do it only in some circumstances.

4. Quality assurance and test automation

In order to consider this activity accomplished you should:

  • Put in place automated testing procedures
  • Execute all types of automated test cases, generate a test report and trace all incidents/defects
  • Perform manual tests
  • Quality assurance team should review reports generated from automation test cases. Conduct all necessary manual test cases to ensure that tests are passing and report incidents/defects

4. Adopt continuous integration

Merging all developer working copies to a shared mainline several times a day can improve the quality of the software and reduce integration issues and conflicts. In fact the longer a branch of code remains checked out, the greater the risk of multiple integration conflicts and failures when the developer branch is reintegrated into the main line.

Agile Key Take Away

  • Preparing a single “definition of done” that meets every situation is impossible. Each team should collaborate and come up with the definition that suits its unique environment
  • Based on the time and the budget at your disposal you can opt for a smart approach or a complete one
  • Organizations that have just started with Agile may find it difficult to reach an acceptable level immediately. I believe that to reach a mature level of adoption large investments are required. In fact, test automation, continuous integration, releases and environments practices and a strong development approach cost money in terms of tools, training, technology, and skill
  • The adoption of project management tools like Jira is mandatory

In my next article, I will try to describe how to identify user stories in a real project from the consultancy point of view.

Please refer to www.scrumalliance.org to have more information on Agile methodologies.

Support us with a small donation:

  • LTC Address: La5f6W1rPr5VHFGCrCmPJ3sSa2AiwKZJbU
  • BTC Address: 1FG1j42MUze8jiW7JbgNaUMZxZeu7M1b4f
  • Ripple Address: rPVMhWBsfF9iMXYj3aAzJVkPDTFNSyWdKy     Tag: 562614972
  • ETH Address: 0x0940958167ca9cbd6409999957a011be7907d904
(Visited 141 times, 1 visits today)
Cristiano Sacco
Cristiano Sacco

Manager with experience in Waterfall and Agile project methodologies.

Project manager with experience in different type of CRM technologies (Oracle-Siebel / Salesforce.com).

Solution architect engaged in several international CRM assessments and capability reviews.

Senior CRM application consultant, with extensive international experience working on large client projects with multi-cultural teams.

Leave a Comment