Grasping the disparity between outcomes vs. outputs in agile is critical for high-performing agile teams. Outputs are the amount of widget parts produced by a person or team. Outcomes speaks to the value or the end benefit, which is a consequence of the work undertaken. Agile teams use empirical process controls (inspection, adaption, transparency) on outputs as well as outcomes. Both outcomes and outputs requires inspection and adaptation.
Examples of outputs are features or stories completed in a Program Increment or iteration. Aggregated, these sets of outputs should derive an outcome, and examples include increased customer loyalty, reduced cost, or risk reduction (to name a few). Outcomes represent the value a team produces to satisfy a customer need.
Examples: Outcomes vs. Outputs in Agile
Some outputs include the following:
Lines of code written
Hours worked
Tasks closed
A burndown chart
A ceremony that was conducted
An automated test case
An iteration or PI Plan
A refined backlog
An experiment
Some examples of outcomes include:
Improved team quality
A proven hypothesis
Reduced risk
Increased brand loyalty
Motivated workforce
Increased product subscriptions
Reduced lead time
Agile teams create Outputs
Agile teams are continuously inspecting the outputs they create. The learning from these inspections provide opportunities to adapt. Agile methods such as iteration backlogs, burndown charts and throughput all service the team to aid their evaluation of delivery.
Focusing on outputs alone will definitely lead to trouble. The aggregates outputs of the team must yield an outcome for a stakeholder. Agile teams use the cone of uncertainty to iteratively experiment with short iterations until the desired outcome is achieved in a viable, feasible, desirable and sustainable way. The team iteratively reduces uncertainty with clarity.
Its important to note that all outputs aren’t equal, i.e. they don’t always derive an outcome. Lines of code written or tasks completed, do not automatically translate to an outcome for our customer.
Agile teams achieve outcomes
The key to unlocking outcomes in agile teams is long-lived agile teams. The team composition includes the Product Owner that owns the team backlog and represents the customer and sets the vision for the product to achieve the customer outcomes. The agile team next key role is the cross-functional, multi-skilled agile team, and a scrum master.
As they work together, they’ll navigate evolve through the stages of team development which is that of forming, storming, norming, and performing (and eventually adjourning). Their common-understanding surrounding the product drives innovation and creativity to product valuable solutions. Agile teams use intentional architecture and emergent design (which, in SAFe, is the premise for extending the Architectural Runway) in their iterations, aligning their product to be fit-for-purpose.
Through their communal evolution and team process, they’ll develop an insightful understanding of the customer. To interrupt the team’s evolution by changing its composition places the entire organization in a regressed state in terms of achieving outcome-based-delivery. er better results and outcomes.
There will be volume of outputs that the agile team produce and will even increase with time, as they become more capable in applying their continuous improvement actions as jointly identified in the team’s retrospectives. The outcomes they’ll create will become the focus of every ceremony, artifact, and role. The iteration review is the mechanism to test their outputs to evaluate actual or planned outcomes. Enterprise support is a prerequisite for this way of working.
Agile Values that enable teams to achieve outcomes
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software (product) frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Working software (product) is the primary measure of progress.
How do we start delivering outcomes?
Understanding outcomes requires us to have a clear grasp on the product vision that solidifies who the target customer is, the anticipated benefits that they will obtain, and also the differentiating factor regarding the value proposition that sets our product apart from the competition. This vision, bundled with a product roadmap depicting product features, creates an relentless product strategy. Every feature that the team brings to fruition has a clear outcome and the team can describe as it as “this feature will allow our customer to…”. With each feature delivery, we zone into the outcome’s sweet spot for the customer.
User stories are an excellent tool for putting the outcome into perspective. This places the agile team in a position to validate that they have achieved the anticipated outcomes. The team’s definition of done ensures that the functionality is usable for achieving the defined (anticipated) outcomes.
With the vision and roadmap in hand, the boundaries for planning Program Increments and iterations, augmented by PI Objectives, iteration goals, and even the stories to achieve said outcomes become clear. Where following agile best practice regarding traceability of tasks to stories, to features, to capabilities, to epics, to strategic themes, the realization of the outcomes can easily be supported.
Outcomes create meaningful value
Agile teams that are high-performing, stable units are infatuated with the achievement of outcomes for their customers. While outputs are key to their process, the teams frequently apply an inspection and adaptation review based on outputs, it’s the outcomes that create meaningful value. Such teams let all their stories, features, roadmaps and visions lead to outcomes. Such teams allow their scrum process constituting every daily stand-up, iteration planning, backlog refinement, iteration review, and retrospective end in outcomes. They maximize transparent processes by assessing the outputs and outcomes along the way using inspection, adaptation, underpinned by transparency.
It’s important to remember that the customer won’t be praising your outputs, as these tend to be disjointed until they are aggregated to formulate an outcome.
What’s next?
Join our Agile Bootcamp training if your team is just starting out with Agile, or join a more advanced course from our Scaled Agile Framework suite or DevOps Institute certification courses.
If you’d like a custom course or workshop, please contact us.
Learn more how Agilocity Consulting can assist you in your journey to an outcome-based culture by booking a call with us via our contact page.
Peruse the associated articles below.
Read the Agilocity Blog.
Subscribe to our newsletter here.