1 | Module | Pattern Name | Pattern | Context | Successes | Challenges | Industry | Organization Size |
|---|---|---|---|---|---|---|---|---|
2 | Backlog Prioritization | Features, Components, Teams | Backlog prioritization is cascading and flows from a single product backlog down to multiple component backlogs, and finally into individual team backlogs. The top-level product backlog is maintained and prioritized by a single Chief Product Owner. It captures, at the feature and epic level, the backlog for at least the next release. The product backlog is refined bi-weekly at a refinement meeting with all component product owners. Refinement sessions focus on readying two sprints of backlog. The Chief Product Owner also holds regular meta-scrum meetings with the stakeholders in the organizations to align on and make visible the prioritization of the backlog. All product feedback flows through the Chief Product Owner, who then reflects the feedback in the prioritization of the product backlog and communication in refinement meetings. The top-level product backlog is categorized by product component (Which part of the product will this feature be added to?) to create component-level backlogs. Component backlogs are owned and prioritized by a single component product owner, who is often also a senior team-level product owner. Each component backlog is refined weekly by the product owners of the teams that work on the component. These refinement sessions focus on breaking down the features into sprint sized stories, and prioritizing these stories along with research and technical debt items identified by the teams for the team-level backlogs. The component-level backlogs are then split by teams to create their sprint backlogs. These sprint backlogs contain at least enough work for the next two sprints on a rolling basis. | Key Drivers: Innovation, enhanced speed of delivery, enhanced customer experience The organization is a market leader and looking to stay ahead of the competition. The company makes multiple products, though this pattern relates to one of those products, which is a legacy desktop product that is being adapted to a Software as a Service model. Releases happen once a year and have historically been disruptive for customers due to the large number of new features in each release. | It provides a degree of centralized vision with the CPO as the main control point, while also responding to change and leveraging team-level knowledge/autonomy through a team of product owners. It has allowed the teams to manage dependencies and produce a more integrated product. This approach covers prioritization, decomposition and planning in one cadence of regular meetings. | This pattern requires overhead effort to maintain the refinement meeting and meta-scrum cadence, as well as discipline to follow-through on refinement and coordinate dependencies across components. The Chief Product Owner has a particularly heavy workload juggling meta-scrums, all product feedback, and weekly refinements with component and team product owners. | Software | 7,000 |
3 | Backlog Decomposition & Refinement | Acceptance Criteria-Driven Planing | Agile projects require as much if not more planning than waterfall projects. We’ve all seen the various examples of agile planning and the related backlog items. The one that I will use here is from cPrime - the “5 Levels of Agile Planning” – Product Vision, Product Roadmap, Release Planning, Sprint Planning and Daily Planning. When using a multi-leveled Agile planning approach, each level of planning drives creation of backlog items (PBI’s) or requirements that get decomposed, becoming more detailed at each subsequent lower level - Themes, Epics, Features, Stories and Tasks. What a lot of teams I come across struggle with “How do we start with the a Theme and decompose down to the Story level? Is there an easy way to do this?” The answer is YES and is it forms the basis of ACDP, that is Acceptance Criteria. We’re all familiar with Acceptance Criteria at the Story level and the role it plays in defining the Definition of Ready and Definition of Done. In ACDP, Acceptance Criteria is defined for all the objects in the model. Starting at the top with Theme, Ac is used to the next level of backlog item. How? Let’s take a look at a real life example. Let’s say your team is tasked with creating iOS 9.0, the latest OS from Apple. Let’s start with a Theme and call it “iOS 9.0”. To easily define the next level down, Epic, define the Acceptance Criteria for the Theme. For example: 1. Device will have 20% improved battery life 2. Device will have more Notes app features 3. Provide directions for public transit for a GPS location 4. Provide Apple “News” as default news app 5. Enable Siri to alert me about Reminders on my calendar Each of these AC now become an Epic – Battery Life, Notes App, Public Transit-enabled GPS, Default News App. For each Epic, define the AC like we did for the Theme. For example, the AC for “Device will have more Notes app features” can be: 1. Able to quickly make check lists 2. Able to add instant formatting 3. Able to add images 4. Able to draw with my finger on the scribble pad 5. Synch Notes across all Apple devices and 3rd party services Each of these AC now become a Feature object – Check Lists, Instant Formatting, Images, Draw on pad. For each Feature, define the AC like we did for the Epic. For example, the AC for “Synch Notes across all Apple devices and 3rd party services” can be: 1. Synch Notes using iCloud for Mac OS and iOS devices 2. Synch Notes across my Google account 3. Able to view/edit Notes in browser Voila! These are now the Story objects. Using a top-down approach to decomposing PBI’s using AC will lead to quick and effective Release Planning. | Like Jeff talks about, it's all about getting from DoR to DoD w/ impediment removal...This pattern will aid in teams becoming hyper-productive - +400% increase in Velocity. | Rapid and clean PBI decomposition...Aids well in using Cucumber for ATDD. | A little more effort upfront. But a disciplined approach will derive even greater benefits - a well groomed BL that is Ready (DoR) which will aid in becoming a hyper-productive team. | Consulting | 1000's |