When is ‘Done’, truly 100% ‘Done’?
5 Dec 2017
When working through any Product Backlog, it’s essential that the whole Scrum Team have a clearly defined and mutually agreed understanding of when each backlog item can be deemed as complete. Without this collective and transparent agreement, teams may struggle to get product backlog items 100% truly ‘Done’ within a Sprint. This is explained further by the Scrum Guide; “When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.” The Scrum Guide (p.16) The below example of ‘Done’ is fairly typical for a team early on in its adoption of Scrum within a corporate environment. Activity (Example) Criteria (Example) Detailed Analysis Acceptance Tests approved by Product Owner. Wiki updated. Detailed Design Consistent with approved design patterns and UI standards. Design approved by Architect. Overall Design Doc updated. Build & Unit Test Consistent with coding standards. Peer Reviewed. 90% automated unit test coverage. All unit tests […]
Scrum is by far the most popular Agile approach. Indeed the terms Scrum and Agile are often used interchangeably and many people are not even aware that there are alternatives to Scrum. Scrum is very simple in its structure and very focused in its scope.
The agil8 Approach
The agil8 approach focuses not only on effective application of Scrum itself, but also integration with essential technical and management practices that it doesn’t cover. These essential technical practices include techniques such as continuous integration, refactoring, test automation and test driven development. Essential management practices include governance, architecture, programme and DevOps portfolio management.
The Scrum Framework
The Scrum framework itself organises work into short iterative Sprint cycles of no more than one month each. Each Sprint should have an agreed Sprint Goal to create an Increment of functionality to production quality, so that it could, if desired, be released.
Scrum Teams are small, cross functional and highly collaborative. The Scrum Framework defines 3 roles which together make up a Scrum Team
- Product Owner
- Development Team members
The Product Owner
The Product Owner works with relevant stakeholders to define the vision for the team, and the Product Backlog of requirements and other work items that will be put to the team. Typically it is a customer or business representative, or a business analyst acting as their proxy.
The Development Team
The Development Team consists of all those people who will do the necessary work to deliver the Product Increment at the end of the Sprint – this includes all necessary activities such as analysis, design build, testing, etc. The ScrumMaster and Product Owner may be Development Team members themselves if they are doing such work as well. The Development Team members determine what work they can do, and how they will do it. They work with the Product Owner to prepare or ‘groom’ the Product Backlog Items that are candidates for each Sprint in advance, and then have a timeboxed Sprint Planning meeting at the start of each Sprint to agree the Sprint Goal and the Sprint Backlog of tasks for the Sprint.
The ScrumMaster facilitates this process, and the other timeboxed Sprint meetings that are part of the Scrum framework. These include:
- a short, daily Scrum Meeting between all Development Team members to synchronise work (the Product Owner may participate in this as well)
- a Sprint Review meeting between the entire Scrum Team and relevant stakeholders at the end of the Sprint, to review the Product Increment and identify candidate Items for inclusion in the next Sprint
- a Sprint Retrospective meeting between Development Team members at the end of the Sprint, to determine what potential improvements to the process will be incorporated into the next Sprint (the Product Owner may participate in this as well)
The ScrumMaster is also responsible for coaching the rest of the Scrum Team in the use of Scrum, encouraging cross-functional collaborative team-working and self-organisation, dealing with impediments to progress that the other members of the Scrum Team cannot deal with themselves and promoting effective use of Scrum across the wider environment.