TeamForm Shared language series
- The Essential Field Guide
- Organisation and team structure
- Strategy and outcomes
- Work and right sizing
- Connecting it all together
Do we need Outcomes and Work?
Before we can answer the question, we need to understand the difference between the two:
- Outcomes are the desired change in behaviour or results from the work performed
- Work items are a breakdown of potential activities that should contribute to the desired outcomes
Note: Finishing work (outputs) does not guarantee that the outcomes are realised.
The benefits of having both and linking them are:
- Organisations: work items can be used to provide alignment from teams up to organisational strategy outcomes. This is often called the golden thread.
- Teams: teams who understand the organisation’s strategic outcomes can contribute more directly knowing that outcomes they can influence through their work support the organisation achieve its broader strategic outcomes. Being able to slice outcomes and work into meaningful slices of value enables teams and the overall organisation to adapt more quickly as their in-progress work can be completed and potentially valuable, rather than work stopped and no benefit received.
What work connects to which outcomes?
There is a difference between outcomes and work. Connecting work and outcomes, enables new levels of transparency and helps teams and leadership understand how work is connected to a given outcome.
Deciding which work item type is appropriate to use as the measure against the progression of your strategy and outcomes. For instance, we cannot use Story/tasks to measure whether a cross-cutting organisation initiative is on track of being delivered because each story/task is too small to realise value of its own and give us the alignment indication.
Finding the right balance is crucial to define this connectivity relationship, with having to factor in the duration boundaries set to complete the work item, details in the scope of the work item and whether the metrics deployed on the work item can be used to indicate value realisation.
Note: Below is an example to demonstrate the connectivity between delivery constructs, multiple teams sharing a common / shared goal and how it can link to work. Visualising a realistic flow is challenging in a static image. Not all teams, outcomes or work need to explicitly have all levels.
e.g. each team doesn’t need to always have their own outcomes / OKRs, they can share them instead (even if the work is different).
Slicing work
What are your levels of work?
Different organisations have different naming conventions and interpretation of what makes up their various levelling of work items. Being able to configure your tools and reporting to represent your language is more important than the specific words. Effective guidance will certainly help new joiners.
Some common work levels used by larger organisations:
- Portfolio > Initiative > Epic > Story
- Initiative > Epic > Feature > Story (popularised by SAFe)
It is not the naming convention of the work items that is important. It is the definition and understanding of the work item levels that creates the common understanding. By slicing work into valuable pieces, teams can deliver value incrementally and planning can become more predictable as a result.
Think of work items and right sizing enabling the organisation to have a common measurement system.
A real-life example in space
Let’s take NASA’s real life example to demonstrate the importance of aligning units of work. Back in 1999, NASA was already sending objects into space to explore Mars and specifically in September 1999 on a day that should have been about celebration turned into horror as the object that they sent to Mars had exploded. This mission failed all due to an Engineer failing to use the right unit of measure i.e. converting English units into metric units!
Coming back down to Earth
Bringing it back to our world today, what can be learnt? This mission failure highlights the importance of ensuring each of your work item units within your organisation is well understood by all so that the communication in the level of detail and scope can be written and delivered by anyone on the team without deviation to the original intent.
What are your investment types of work?
In our previous blog post Capacity-based Funding Model: The Essential Field Guide | Field Guide | Expert Insights we explained the need to define parent investment types in order to remove the pressure of individuals having to accurately monitor their % effort through cost centre codes.
This can reduce the need for time booking and simplify how work items get categorised within a portfolio.
This enables a portfolio of investments to be assessed from the lens of:
- does the investment of capacity make sense relative to the investment type (e.g. is the portfolio overspending on technical debt, under investing in new capabilities etc.)
- does the work delivered contribute to the outcomes of the teams and organisation (e.g. does the work delivered change customer behaviour or are the planning assumptions wrong?)
- is it possible to see how the teams work is linked to the team and organisations outcomes (e.g. OKRs and work linked)
How should teams size work?
There is a misconception that human capacity is equivalent to delivery capacity, according to PlanView’s 2023 Project to Product State of the Industry Report:
92% of businesses do not have the foundation for a product-oriented model, causing their digital transformation efforts to fail.
Business leaders believe their IT and software development teams, in charge of transformation efforts, can deliver 10x more than their actual capacity, leading to team burnout40% of digital innovation work from IT and engineering teams are wasted due to shifting priorities at the C-level.
Only 8% of what’s planned by IT and software development teams gets delivered, inefficiency that can no longer be ignored given today’s cost and performance pressures.
To break this misconception, right sizing is a pragmatic approach for teams to forecast what they can deliver using historical data over a period.
Imagine a team sizing their work as ‘1 small work item’ from bug fixes through to new feature build, how long do you think some of their work will be stuck in the ‘in-progress’ state? Without right sizing, the team’s predictability is limited, teams risk starting more work than can finish, which further impacts lead time. This leads to work item ageing and slowing throughput and creating escalations just to get basic work done done. When that happens it is hard for teams to be able to invest in learning and continuous improvement.
How should work be linked to teams?
In complex organisations dependencies are inevitable, however how dependencies are dealt with is a choice you can make and a set of established behaviours that the organisation takes to continuous improvement and reducing unnecessary dependencies over time.
Managing dependencies is not enough, that keeps them in play and creates a culture of delivery roles being needed to “get things done”. Delivery roles should support teams in identifying dependencies, facilitating the teams being depended on and then collaborating on an approach to eliminate or at least reduce the dependency for the team and others in the future.
You likely already know of one of the teams in your organisation that everyone depends upon, sometimes that is the login or authorisation team, or the data transfer team. They are likely stuck using outdated technology and spend most of their time working on escalations and fire-drills and never get any time to improve their product or service offering.
Visualising dependant teams is one option if your tooling supports it, otherwise you can at least link work from your team to the dependant team's backlog or work item. Linking work from one team to another rarely creates a healthy collaborative approach and quite often is ignored when teams are too busy and under pressure from escalations. Their prioritisation approach will end up being HiPPO (Highest Paid Person’s Opinion) driven.
When managing dependencies, talk to your dependant teams before you commit to a plan and invite them to collaborate on a shared outcome (OKR). This way both teams are seen as contributing to the same goal or outcome and the dependant team isn’t just taking orders from someone else.
Other options and techniques exist around identifying, managing and eliminating / reducing dependencies, however that is likely a dedicated article or talk. Check out Tory Magennis' course and talk (below) to get you started.
Other useful practices
- Establish a common backlog across a team of teams or value stream to enable capacity planning, ensure that teams have a health work in progress limit (stop starting, start finishing type approach).
- Ensure you have a team of teams or value-stream based board, so that all teams can be on the same page (big picture view).
- Establish a minimum workflow for teams and their work to support the team of team level board (avoid over constraining how teams work and customise their boards).
- Establish a cadence to support raising / identifying dependencies and then a continuous improvement approach to eliminate or at least reduce the dependencies over time.
Work is not as simple as the creating tasks, work items act as a communication vehicle to the organisation in terms of predictability, progress and an early warning system to impacted outcomes.
When creating your work item shared language, consider how work will aggregate and link to parent items, related outcomes (OKRs) and other teams (dependencies).
Additional resources
- Dependency Management - capture, fix, and avoid (Troy Magennis' course on Dependency Management)
