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 […]
SAFe Scaled Agile Framework
SAFe™ – the Scaled Agile Framework® – is an increasingly popular approach for implementing Agile practices at enterprise scale. Initially outlined in several books by Dean Leffingwell, the approach draws upon and combines elements of Lean thinking, Agile development techniques and concepts of Product Development Flow. Through field experience at enterprise scale in many organisations, SAFe has evolved into a broad and deep framework of guidance, which can be accessed on-line at www.scaledagileframework.com.
The approach is structured into a three level pattern, which is designed to be tailored and adapted with additional or fewer levels as required for each implementation. The first of these is the Agile Team level, which is based on Scrum and eXtreme Programming (XP) with multiple teams delivering User Stories. Beyond the Team level, SAFe is aimed at programmes involving around 50 people or more. The Programme level serves to help the Agile Teams co-ordinate their collaboration on Features through Release ‘Train’ planning and the advance definition and creation of Architectural ‘Runway’. At the overall Portfolio level, a Kanban based approach is used for the definition and management of both Business and Architectural Epics against Investment Themes and their Vision and Roadmap.
The Portfolio Level
At the top level in SAFe the Portfolio Management function turns the organisation’s strategy into a set of Investment Themes, typically for the next 6-12 months. Percentage allocation of budget and resource is agreed to ensure each theme receives appropriate focus as planning commences and lightweight Business Cases are produced. Business and Architectural Epics to support each Investment Theme are defined on a Portfolio Backlog of large scale development programmes which will span multiple releases. A Kanban-based pull system is used to manage the flow of Epics and ensure that the economic basis for decision making is quantitative and transparent.
The Programme Level
The Programme level provides the essential glue to ensure that the work of the Agile teams is aligned with the organisation’s strategic Vision and Roadmap for each Investment Theme. Programme level Product and Release Management is designed to help prevent the work of multiple Agile teams becoming mis-aligned and difficult to integrate. SAFe provides a number of tools and techniques to address the typical challenges of focussing the efforts of large programmes to deliver maximum return on investment (ROI).
At the Programme level business and architectural Features are defined and ordered in a Programme Backlog. Release ‘Train’ Planning is performed by teams together on a regular cadence, typically every 2-3 months. Potential Shippable Increments (PSIs) of business functionality are used for planning with Hardening/Innovation/Planning Sprints used as necessary to ensure delivery on demand. The evolving architecture necessary to support new business functionality is also planned and developed ahead of the business functionality as an Architecture ‘Runway’ that it can ‘land’ on. In addition, a System Team is often established to create initial infrastructure and then support and share the Agile teams’ system-level continuous integration and end-to-end testing efforts.
The Team Level
At the Team level, SAFe recommends use of Scrum plus XP technical practices to ensure high quality. Each Agile Team has a Product Owner and Scrum Master and works in Sprints to deliver new architecture and User Story functionality. In addition, Agile Teams collaborate in Release Train Planning and each has its own Team Backlog and PSI Objectives. Thus whereas Scrum focuses on the Agile process for a single team and has little to say about multi-team environments, SAFe goes far beyond concepts like Scrum-of-Scrums to ensure that large programmes can see the wood for the trees and deliver maximum ROI in line with their Vision, Roadmap and Portfolio Investment Themes.