Intake Work - A New Process Goal
From the Disciplined Agile Blog
by Tatsiana Balshakova,
Mark Lines, Mike Griffiths, James Trott, Bjorn Gustafsson, Curtis Hibbs, Scott Ambler
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.
View Posts By:
Tatsiana Balshakova
Mark Lines
Mike Griffiths
James Trott
Bjorn Gustafsson
Curtis Hibbs
Scott Ambler
Past Contributors:
Joshua Barnes
Michael Richardson
Daniel Gagnon
Valentin Tudor Mocanu
Kashmir Birk
Glen Little
Klaus Boedker
Recent Posts
DA 5.6 is released
Disciplined Agile 5.5 Released
Choose Your WoW! Second Edition Is Now Available
Requisite Agility applied in Project Management
Disciplined Agile and PMBoK Guide 7th Edition
Categories
#ChoiceIsGood,
#ChooseYourWoW,
#ConsumableSolution,
#ContinuousImprovement,
#CoreAgilePractices,
#experiment,
#Experimentation,
#GuidedContinuousImprovement,
#Kaizen,
#LifeCycles,
#ProcessImprovement,
#TealOrganizations,
Adoption,
agile,
agile adoption,
Agile Alliance,
Agile Business Analyst,
Agile certification,
agile data,
agile governance,
agile lifecycle,
agile metrics,
agile principles,
agile transformation,
Agile2018,
Agile2019,
Agile20Reflect,
AgileData,
Analogy,
announcement,
Architecture,
architecture,
architecture owner,
Articles and publications,
Asset Management,
Atari,
Backlog,
Barclays,
being agile,
benefits,
bi,
blades,
book,
Branching strategies,
Browser,
Business Agility,
business intelligence,
business operations,
capex,
Case Study,
Certification,
certification,
charity,
Choose your WoW,
CMMI,
cmmi,
Coaching,
Collaboration,
Communications Management,
Compliance,
Compliancy,
Conference,
Construction,
Construction phase,
Context,
Continuous Improvement,
coordination,
COVID-19,
Culture,
culture,
Cutter,
DA,
DAD,
DAD Book,
DAD discussions,
DAD press,
DAD roles,
DAD supporters,
DAD webcast,
DADay2019,
Data Management,
database,
dependencies,
Deployment,
Development Strategies,
DevOps,
disaster,
Discipline,
discipline,
Disciplined Agile,
disciplined agile delivery,
disciplined agile delivery blog,
Disciplined Agile Enterprise,
disciplined devops,
Documentation,
Domain complexity,
dw,
DW/BI,
Energy Healing,
Enterprise Agile,
Enterprise Architecture,
Enterprise Awareness,
enterprise awareness,
Essence,
estimation,
Evolving DA,
Executive,
Experiment,
facilitation,
FailureBow,
feedback-cycle,
finance,
Financial,
FLEX,
Flow,
foundation layer,
Funding,
GCI,
GDD,
Geographic Distribution,
gladwell,
global development,
Goal-Driven,
goal-driven,
goals,
Governance,
GQM,
Guideline,
Hybrid,
Improvement,
inception,
Inception phase,
India,
information technology,
infosec,
Introduction,
iterations,
Kanban,
large teams,
layer,
lean,
Lean Startup,
learning,
Legal Project Management,
LeSS,
Lifecycle,
lifecycle,
Manifesto,
mark lines,
marketing,
MBI,
Metaphor,
Metrics,
metrics,
mindset,
Miscellaneous,
MVP,
News,
News and events,
Non-Functional Requirements,
non-functional requirements,
Non-solo development,
offshoring,
Operations,
opex,
Organization,
Outsourcing,
outsourcing,
paired programming,
pairing,
paper,
People,
People Management,
phases,
Philosophies,
Planning,
PMBoK,
PMI,
PMI and DA,
PMI Chapter,
Portfolio Management,
post-format-quote,
Practices,
practices,
Principle,
Process,
process improvement,
process tailoring,
Product Management,
product owner,
Product Owners,
productivity,
Program Management,
Project Management,
project-initiation,
Promise,
Quality,
quality,
rational unified process,
Refactoring,
Reiki,
Release Management,
release management,
Remote Training,
Remote Work,
repeatability,
requirements,
Requirements Management,
research&development,
responsibilities,
retrospectives,
Reuse,
Reuse Engineering,
ride for heart,
rights,
Risk Management,
Risk Management,
Risk management,
Roles,
RUP,
SAFe,
sales,
Scaling,
scaling,
scaling agile,
Scheduled Workshops,
SCM,
scorecard,
Scrum,
ScrumMaster,
SDLC,
Security,
security,
self-organization,
SEMAT,
serial,
skill,
solutions software consumable shippable,
Stakeholder Management,
strategy,
Support,
Surveys,
Teal organizations,
team development,
Team Lead,
team lead,
Teams,
Technical Debt,
Teleconferencing,
Terminology,
terraforming,
test strategy,
testing,
time tracking,
Tool kit,
Toolkit,
tools,
traditional,
Transformation,
Transition iteration,
transition phase,
Uncategorized,
Upmentors,
Using PMI Standards,
value stream,
velocity,
vendor management,
Virtual Training,
Workflow,
workflow,
workspaces
Date
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)
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)
Related Resources
Posted
by
Scott Ambler
on: July 20, 2021 07:06 AM |
Permalink
Comments (7)
Please login or join to subscribe to this item
The options from "Consider new work" are synchronized with Scrum and Kanban, but are less synchronized with DA.
DA delivery - we consider new work first on release inception and later continuously/per iteration.
DA value stream - we consider new work first per each MBI / MVP (that also contains a delivery release) and later continuously/per iteration.
Without MBI/small releases logic we can accept new work and increase too much the release scope without any delivery.
The intake process ~ could have more "waves". We need MBI/small release to be sure that we have often delivery (basic principle for both agile and lean). Then we can accept changes before delivery continuously/per iteration depending on the used life-cycle.
More: the size of the MBI could be different depending on the selected life-cycle. Decreasing order: Agile or Lean, Continuous Delivery Agile, Continuous Delivery Lean.
My proposal is to introduce a new decision factor: Business Increment type, that could be related to MVP, MBI, and life-cycle options, and "new work" will remain as new work inside the business increment.
Scott Ambler
Consulting Methodologist| Ambysoft Inc.
Toronto, Ontario, Canada
The arrival of potential work happens when it happens for a given team. A team will choose to process it when it is appropriate for them. A team following the Agile life cycle, which is based on Scrum and is phased to support a project-based approach, may choose to intake work in a big batch at the beginning of Inception and then at the beginning of each iteration/sprint during Construction. A team following a Continuous Delivery: Lean lifecycle would intake work as it arrives. Different life cycles, different tailorings of this process goal.
Scott Ambler
Consulting Methodologist| Ambysoft Inc.
Toronto, Ontario, Canada
What would the benefit be of a "business increment type" as a decision point? It's an interesting idea, but we only want to add things if there's a clear reason to do so.
The first decision in "Choosing WoW" is related to life cycle selection ~ and when & how we will deliver. These options are somehow outside of the Toolkit content.
If we want to have an end-to-end view of the development and value stream, it is important when we do new work and when we deliver. The main decision is related to the business increment: the initial intake and the size and cadence of the delivery.
The initial input can be changed iteratively or continuously. However, if we decide the new work intake between the two mentioned variants (iteration / continuous) we do not have also a decision on the time of delivery. The main goal is not about the standalone intake, but about the intake, and delivery ~ a full life-cycle.
The new Scrum (2020) also proposes these two options, but they still don't say anything about the business increment. Yes, with the new Scrum we can deliver whenever we want, but it is a completely ad-hoc process.
There is a high risk of deciding on new work intake between iterations / continuous, but to release after a too long period.
One of the main ideas from agile & lean is to reduce the WIP and accelarate delivery, so IMO we should related the intake and delivery concepts.
The rest of the process decisiosn are strongly related to both intake and delivery decisions.
The DA approach for intake is the same as for planning: Rolling Wave and that suppose different levels (that should be also IMO a decision factor): roadmaps, business increments, iterations inside increments, very small internal increments inside business increments. The Scrum approach is to talk only about the middle-low level (iteration and from 2020, also small increments). For Scrum, the roadmap and business increments levels intake is just hidden magic. I do not think that we want a similar approach.
DA Toolkit 5.2 is not on this website. Where can I see the latest version?
Please Login/Register to leave a comment.
