Project Management

Disciplined Agile

by , , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Tatsiana Balshakova
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths
Scott Ambler

Recent Posts

Disciplined Agile and PMBoK Guide 7th Edition

Comparing Agile and Lean Backlog Strategies

Disciplined Agile 5.3 Released

Measure Outcomes - A New Process Goal

Organize Metrics - A New Process Goal

Comparing Agile and Lean Backlog Strategies

Categories: agile, Backlog, lean, Requirements

One of the changes that we made in the DA 5.3 release on September 30th was to update our advice around managing backlogs. We had been using older terminology from when we first developed Disciplined Agile Delivery (DAD) and we had an out-of-date description of what was being advised in the Scrum community (they've adopted a more disciplined strategy in recent years).  So we've acted and updated this aspect of the tool kit.

Recent Refactorings

There are three refactorings that are pertinent to our discussion:

  1. Introduction of the Intake Work process goal. In the DA 5.2 release of July 9th, 2021 we created a new process goal, Intake Work by refactoring it out of the existing Address Changing Stakeholder Needs process goal.  The Intake Work process goal is depicted in Figure 1. The reasons for this refactoring was that Address Changing Stakeholder Needs wasn't cohesive in that it had two purposes, the first to explore the changing needs and the second to intake the work into the team.   
  2. Introduction of the Manage Backlog decision point. For the 5.3 release we refactored further, and split the Manage Work Items decision point into two, creating the new Manage Backlog decision point.  The reason for this refactoring was that the original decision point wasn't cohesive, it had two purposes, the first to capture strategies to manage backlogs and the second to manage/visualize work items.
  3. Update to Explore Scope. We updated Explore Scope's Choose a Backlog Management Strategy decision point to reflect the changes we made to Intake Work.

 

Figure 1. The Intake Work process goal.

 

Managing Backlogs

As you can see in Figure 1 there are four fundamental strategies for managing your backlog of work.  These strategies are ordered, you know this because there is an arrow beside the list, indicating that the strategies towards the top of the list are generally more effective than the strategies towards the bottom.  In order from most effective to least effective, these strategies are:

  1. Lean backlog. Lean backlogs are typically organized into four groupings: Potential work that the team may commit to; Committed work that the team will perform, which is typically sequenced into several classes of service; Work in process (WIP) that the team is currently performing; and completed work that is ready to move on to the next stage in your overall process.  Lean backlogs are overviewed in Figure 2. 
  2. Agile backlog. Work items are managed as an ordered list/stack. Higher-priority work items appear at the top of the list, are granular and captured in greater detail, and are sequenced.  Lower-priority work appear towards the bottom of the list, lack detail, and are effectively in unsequenced priority buckets. In previous versions of DA we referred to this strategy as a Work Item List and it has always been our default recommendation for agile team.  This strategy was an extension to Scrum's (at the time) product backlog which was a prioritized list of requirements, but over the years Scrum's approach has evolved into this more disciplined strategy. Agile backlogs are overviewed in Figure 3.
  3. Requirements (product) backlog.  A unique, ranked stack of requirements that needs to be addressed. Requirements at the top of the list should be captured in greater detail than lower-priority requirements at the bottom of the list. In earlier versions of Scrum this was a prioritized list of functional/usage requirements, often captured as user stories.  Some teams would include defects and some form of quality requirements (often captured as technical stories) on the backlog, as they were considered valid requirement types as well. Requirements backlogs are overviewed in Figure 4.
  4. Unsequenced backlog. All of the work is effectively the same priority, although sometimes there may be the concept of two priorities - what is in the current release and what needs to be in future releases.

 

Figure 2. Lean backlog overview.

Lean backlog overview

Figure 3. Agile backlog overview.

Agile backlog overview

Figure 4. Requirements (product) backlog overview.

Requirements (product) backlog overview

 

Comparing Backlog Strategies

The following table compares the four backlog strategies.  For more information, please refer PMI's Disciplined Agile (DA) Browser.

Table 1. Comparing Backlog Strategies
Backlog Strategy Advantages Disadvantages
Lean
  • Best where priorities are changing continually.
  • Easily supports several work sequencing schemes in parallel.
  • Harder to see the work as a single stack of sequenced work items if there are multiple classes of service.
  • Requires discipline to pull new work fairly from the various classes of service. It's common to see one or more classes, such as paying down technical debt, starved in favor of implementing new functionality.
Agile
  • Best suited where the team follows one of the agile life cycles.
  • Clearly indicates the order in which work will be performed, enabling effective prioritization discussions with stakeholders.
  • Supports the forecasting of cost and schedule estimates via techniques such as burndown or burnup charts.
  • Requires ongoing maintenance and refinement, adding overhead to your process.
Requirements (product)
  • Clearly indicates the order in which work will be performed, enabling effective prioritization discussions with stakeholders.
  • Supports the forecasting of cost and schedule estimates via techniques such as burndown or burnup charts.
  • Forecasts tend to be overly optimistic due to non-requirement work not being accurately taken into account.
  • Requires ongoing maintenance and refinement, adding overhead to your process.
Unsequenced
  • Enables the team to perform the work the the order they deem to be the most effective.
  • You don't know what's next to be worked on, making it more difficult to do look-ahead planning/refinement.
  • Team members tend to work on what they want to, or what they find easy.
  • By not working in priority order, when the team runs out of time or funding, they risk missing critical functionality because it needed to be cut.

 

 

Acknowledgements

I'd like to thank Curtis Hibbs and Klaus Boedker for their great work on Figures 2-4, which I reused from our upcoming Disciplined Agile Product Owner workshop.

 

Posted by Scott Ambler on: October 04, 2021 12:03 PM | Permalink | Comments (13)

Disciplined Agile 5.3 Released

Categories: agile, Disciplined Agile

Disciplined Agile LogoWe released Disciplined Agile (DA) v5.3 earlier today, September 30th 2021.  While there are several visible changes that we've made, discussed below, most of this release is "behind the scenes" in that we've updated descriptions of many techniques and added many new references that link to articles, blogs, or books describing a given technique.

The "visible changes" include updates to several process goals:

  • Intake Work. We refactored out several options from the Manage Work Items decision point to introduce a new decision point, Manage Backlog. We also updated the options for backlog management to reflect current industry practice.  This is a fairly important change that will be described in a detailed blog post.
  • Explore Scope. We updated the Choose a Backlog Management Strategy decision point to reflect changes to Intake Work. Early in a project it's critical to identify how you will manage your backlog later during Construction as this decision will inform your decision around how much detail to gather during Inception.
  • Measure Outcomes. We added several new potential metrics to existing options, and introduced the Increase Initiative Health decision point.
  • Organize Metrics. Added Aggregate Measures and Report Measures decision points.  An earlier blog, Apply Consistent Metrics Categories Across an Agile Portfolio, covers the key strategy for aggregating measures.  The report measures decision point is self explanatory, covering strategies such as status reports, metrics reports, automated dashboards, and more. 
  • Plan The Release. Updated estimation strategies.

We also updated the following process blades:

  • Continuous Improvement – Added the Analyze Root Cause decision point to the goal diagram.
  • Product Management – Added the Measure Offering decision point to describe explicit measurement options. Added the Capture Roadmap decision point to describe options for documenting/communicating your product roadmap.

It is important to note that for the DASM and DASSM exams that we are still testing you against the DA 5.0 version of the model.

Related Resources

Posted by Scott Ambler on: September 30, 2021 06:59 AM | Permalink | Comments (8)

Measure Outcomes - A New Process Goal

Categories: agile, goal-driven, goals, Scrum

We recently released the 5.2 version of the Disciplined Agile (DA) tool kit, and in that release we added three new process goalsIntake WorkOrganize Metrics, and Measure Outcomes.  The focus of this posting is the Measure Outcomes process goal, the goal diagram for which is posted in Figure 1.

 

Figure 1. The Measure Outcomes process goal diagram (click to enlarge).

Measure outcomes process goal

The Measure Outcomes process goal describes potential improvement outcomes, or improvement goals, and suggests potential metrics to measure progress against those outcomes. Disciplined Agile doesn't prescribe what to measure, that would be naive because every team is unique with its own priorities and desired outcomes. 

All of the potential outcomes in Figure 1 are important.  However, you will want to focus on a subset at any given time, and that subset is likely to evolve as your improvement focus evolves. Context counts. 

 

 

Related Resources

Posted by Scott Ambler on: July 22, 2021 12:00 AM | Permalink | Comments (3)

Organize Metrics - A New Process Goal

Categories: agile, goal-driven, goals, Scrum

We recently released the 5.2 version of the Disciplined Agile (DA) tool kit, and in that release we added three new process goalsIntake WorkOrganize Metrics, and Measure Outcomes.  The focus of this posting is the Organize Metrics process goal, depicted in Figure 1.

 

Figure 1. The Organize Metrics process goal diagram (click to enlarge).

Organize metrics process goal

As the name implies, this process goal describes strategies to organize the metrics approach within your team. This strategy will be driven both by your team's culture and skills as well as the needs of your stakeholders - your metrics will likely need to "roll up" to the program or portfolio level.

Your metrics strategy will focus on several important questions:

  • What is the focus of our measure strategy?
  • How will we communicate measures both within the team and externally to our stakeholders?
  • How will we measure?
  • What types of measures will we take and communicate?

Where this goal focuses on how to measure, the Measure Outcomes goal describes what to potentially measure.

 

 

Related Resources

Posted by Scott Ambler on: July 21, 2021 12:00 AM | Permalink | Comments (0)

Intake Work - A New Process Goal

Categories: agile, goal-driven, goals, Scrum

We recently released the 5.2 version of the Disciplined Agile (DA) tool kit, and in that release we added three new process goals: Intake Work, Organize Metrics, and Measure Outcomes.  The focus of this posting is the Intake Work process goal.

Intake Work: Added

Figure 1 depicts the process goal diagram for Intake Work (see How to Read Process Goal Diagrams).  This is how a team pulls in work from their "upstream" stakeholders. The incoming work is examined and if ready it is prioritized and put on the team's work backlog. We introduced this process goal because we wanted to have a cohesive source of process information capturing the issues around a common activity that is critical to your team's success.

Figure 1. The Intake Work process goal diagram (click to enlarge)

Intake work process goal diagram

 

To be effective at intaking work, we need to consider several important questions:

  • When are we going to accept any new work?
  • Is the request work ready for us to accept?
  • How are we going to prioritize work?
  • Who will prioritize the work?
  • What types of work needs to be prioritized?
  • How are we going to manage work items?

 

Address Changing Stakeholder Needs: Refactored

Part of the development of Intake Work was the refactoring of Address Changing Stakeholder Needs which previously captured several decision points that focused on intaking work and several on exploring stakeholder needs.  Figure 2 depicts the updated goal diagram.  Important changes include:

  • Several decision points - Prioritize Work (What), Prioritize Work (Who), Prioritize Work (How), and Manage Work Items - were moved from here to Intake Work.
  • The Explore Stakeholder Needs decision point was moved here from Produce a Potentially Consumable Solution, simplifying that goal and helping to focus this one.

Figure 2. The Address Changing Stakeholder Needs goal diagram (click to enlarge)

Address changing stakeholder needs process goal diagram

 

Related Resources

Posted by Scott Ambler on: July 20, 2021 07:06 AM | Permalink | Comments (7)
ADVERTISEMENTS
ADVERTISEMENT

Sponsors