While there are multiple ways to keep a check on the health of a project in Scrum, not having clearly defined what is done can lead into failure. It is important to define the exit criteria for each and every stages of your project starting from story to software release to production.
Here is a quick reference to “definition of done” in Scrum i.e what it meant to be done with a story, a sprint, a release to your integration environments and, last but not least, your release to production environment.
The below is not a complete list but gives you an idea to “Definition of Done” at each stage. You could define your own based on your project environment. You would need to define “done” for all four stages stated below:
2. A Sprint
3. Release to Integration Environments
4. Release to Production Environment.
What does done with a Story mean..
All code tested
All code checked in
All unit tests passing
All acceptance tests identified written and passing
Functional test passing
What does done with a Sprint mean..
All Story criteria met PLUS
Product backlog updated
Performance Testing done
All bugs closed or postponed to next sprint
Code coverage to all unit tests is 80%
What does done with Release to integration mean..
All Sprint criteria met PLUS
Installation package created
Operation guide and troubleshooting guide created
All test suits passing
What does release to product mean..
All integration met PLUS
Stress testing done
Performance Testing done
Network diagram updated
Security Validation pass
Scrum framework can be applied to maintenance or support kind of work too. There is a misconception that the Scrum framework doesn’t hold good for maintenance work. Actually, it may look a little challenging initially to tailor Scrum to fit sustenance. Here is a brief on what could be done.
Generally, Support/Maintenance work involves lot of churn. Changes happen almost daily. Team has to work on high priority customer issues and sprint plan will keep getting interferences (unpredictable user stories) and tasks may need to be added in the middle of a Sprint. Maintenance project may not have releases as in the case of development projects. How do we handle this?
Important thing to note here is to have a short Sprint. Generally 1 Week Sprint. This will make the Sprint Plan to focus on priority items that need to be worked, through out the week and to resolve issues. This will make customer happy.
Keep more buffer time while planning the sprint – You never know if an escalated issue might land in your bin that may override all other current issues. If you have about 20% buffer time, you may be comfortably handle priority items without much impacting the sprint plan. If not new issues come, we just continue with the work and if there is bandwidth left, we may pick up more issues from the issues-pool.
Scrum-ban technique is being adapted by many. It is a combination of Scrum and Kanban method. It mainly categorizes support tasks in to “Not started”, “In progress”, “Done” on a white board. Post its with task description will be used to categorize the current pool of tasks. For more do check this nice article.
« go back — keep looking »