The Cone-shaped Backlog

Here’s an approach I’ve found successful when helping teams ensure their backlog supports optionality, handles uncertainty and continuously adjusts so their goals and strategies are aligned to their vision.

A backlog should have these qualities

The backlog is made-up of backlog items. Each item represents a business goal, which when delivered by the team, will provide a beneficial outcome to the business and its customers/stakeholders.

Qualities of the backlog:

  • Easy to update by the product owner
  • Should be available to everyone in the business
  • Shows the backlog items for the next sprint
  • Conveys a vision of the future with a tangible path to the present
  • Reflects vagueness and options
    • If a distant backlog item is too vague to describe in words, consider drawing a picture, as shown in the photo below
  • Self-explanatory to anyone in the business

The cone-shaped

I often encourage teams to visualise the backlog in a cone-shape in this manner:

  • The neck of the cone shows the current sprint goals
  • The widest point of the cone shows the furthest goals which may be months or years from now.
  • The centre of the cone shows the goals for the intervening time periods. This area can be divided into sprints, months, quarters and half-year intervals.
Backlog visualised as a cone.

Reason for the cone-shape

  • It reflects the cone of uncertainty, where the further out the team considers, the less certain they are of the future environment.
  • The narrow neck of the cone reflects the fact the team can only sustainably deliver a small number of goals. Invariably there is more demand than the team can supply, so the team should gradually constrain the number of goals as the time nears the current sprint.
  • The further into the future, the more the team can consider a wide number of options. This optionality allows the team to consider many possibilities and scenarios without having to commit earlier than necessary. However, as time draws nearer, and as the cone gets narrower, the team will need to reduce the number of options based on the insights they have gathered.

Additional information which supports the backlog

As shown in the photo above, to enable continuous alignment across the business, there is additional information I advise teams to use:

  • Vision Statement: This is a short easy-to-understand statement which describes what the team intends to achieve. It’s written by the team, with their sponsor and stakeholders. The vision statement ensures alignment for the team, with those they serve and with those whom the team may rely upon.
  • Strategies: These are the current set of approaches the team have reasonable confidence in that if delivered successfully, will help fulfil the vision statement.
  • KPIs: These Key Performance Indicators are a small selection of measures which indicate whether the team’s strategies and sprint goals are achieving the team’s vision.
  • Epics start and end dates: Epics are goals which span more than one sprint. On the backlog, the likely start time of an epic is positioned with a blue post-it note; the likely end time is positioned with a pink post-it note.

Further Reading

Inter-team qualities for Business Agility

Business Agility is an enterprise-wide mechanism to rapidly sense, respond and deliver the right business initiatives that will benefit an organisation and its customers.

To increase business agility, an organisation needs to promote the qualities of collaboration, alignment and synchronisation amongst its teams and departments. This creates cohesion to the organisations strategic goals.

Governance processes should be built around these qualities since it affords individuals and teams a great degree of freedom to pursue the organisation’s goals and outcomes. It will also help close the gap between strategic direction and day-to-day team execution.

Consider scaling team frameworks such as Scrum to create ways of working that promote these qualities.

Collaboration

Regardless of background, seniority or specialism, teams and individuals from across the business should have the freedom to collaborate. Collaboration can extend beyond the business to include business partners and clients.

Managers should help the business to reorganise so that cross-functional teams of specialists, regardless of department, can work as single teams to rapidly experiment and deliver business outcomes.

Alignment

All individuals should understand and be aligned to the organisation’s mission, vision and strategic direction. Each team and department should have clarity of the business outcomes that are currently being sought.

Leaders should enthuse and align their colleagues; managers should create the environment and ways of working with their colleagues which reduces misalignment.

Synchronisation

Creating cross-functional and co-locate delivery teams can greatly improve business agility. However, despite this, often a single team cannot deliver products and services on their own. Often many teams need to be involved, which necessitates the synchronisation of effort across many teams.

To illustrate this Klaus Leopold gives a useful analogy which I’ve expressed as the following:

A customer wanting to have a letter written, where each team works independently by controlling a row of keys on a keyboard. Typing the letter would be uncoordinated, slow and frustrating.

To improve time to market, it’s inevitable that teams need to interact. So, rather than teams independently hitting their keys at speed, it’s better if each team slows down, coordinate and collectively hit the keys at the right time and sequence.

Setting-up Effective Teams

For a team to effectively deliver valuable business outcomes, they should typically be set-up with the characteristics describe on this page. These characteristics will also help ensure the team is aligned to the organisation’s strategy and fulfil the needs of customers and clients

These characteristics are rules of thumb. Any compromises and trade-offs against these characteristics are likely to reduce team effectiveness and delay delivery. With continuous leadership guidance and coaching, the team should regularly review and make adjustments to find the sweet spot.

These characteristics can be viewed as enabling constraints, in that they are set of conditions which, although constraining, will enable the team’s alignment to business needs, handle uncertainty and deliver value effectively.

Each characteristic has an interactive slider. Use the slider to reveal the trade-offs and compromises for the characteristic.

Small team size over large team size

Small teams reduce the number of people who need to be kept up-to-date and therefore increases the team’s cohesion and nimbleness. Between five to nine people is the optimum.

Click on the circles to reveal the trade-offs

Co-located over distributed team

Teams who sit together are able to share, discover and deliver with the least barriers to communication. Empathy and effectiveness are maximised. When the team members are distributed, the benefits of non-verbal communication (e.g. body language) and emergent rituals are constrained.

The more the work is uncertain, complex and varied, the more the team should choose to co-locate. On the other hand, if the work is familiar, predictable and routine, then the team could be distributed.

Full-time over multiple endeavours

Teams who are full-time on a single project or initiative have the least amount of distraction. They don’t suffer the overhead of context-switching between different work.

Cross-disciplined over siloed specialisms

Teams are most effective when they have everyone they need to take a requirement through to delivery. They won’t be hampered by having to wait for, or gain sign-off from, external parties. Individuals should be T-shaped meaning they have the breadth of competencies and willingness to switch between a number of roles within the team.

Self-managing over external management

If the team has the clarity of their mission and have the competency to deliver the mission, they are best placed to discover how to manage themselves and decide how work should be delivered.

Emotional intelligence over a narrow worldview

The team should be made up of individuals who have the capability to recognise their own emotions and those of others. In a composed manner, they should use emotional information to guide thinking and behaviour, and professionally handle the inevitable trial and tribulations to achieve their team goals.

Long-lasting over short-term teams

It takes time for team members to understand each other’s preferences, nuances and specialists, and time for the team to form its culture and ways of working. Once the team has stabilised and is highly performant, be careful not to break-up the team without a compelling reason.

Leadership support over distant management

Attempting to deliver business value, particularly for new business initiatives, is inherently uncertain. Teams need support from leaders to ensure strategic alignment. Leaders should remove organisational impediments and negotiate with staunch traditionalists.

Close to customers over proxy interpretation

In order for the team to reduce the feedback cycle between learning and deliver, they must be closest in the organisation to the customers or clients. Any intermediaries will slow the feedback cycle, increase misinterpretation and reduce customer retention.

Notes

Thanks to Tom Broughton for helping me strengthen this article.

Measures for team effectiveness. And a caveat.

I suggest there are only three measures leaders should examine when considering a team’s effectiveness. However, read to the end to understand the dangers of measuring team effectiveness.

  1. The team’s track record of delivering outcomes that addresses user/client/stakeholder needs. This is the ultimate arbiter of team effectiveness. Emphasis: Building the right thing
  2. The typical time it takes for the team to start working towards an outcome, to the point the outcome has been achieved. In other words the cycle-time.  Emphasis: Building the thing fast
  3. Particularly if it’s a software team, their level of tech debt. This allows leaders to understand the team’s ability to maintain service and deliver further business outcomes. Emphasis: Building the thing right

Considering any more measurements will run the risk that leaders get blinded by proxy information, and risks them misjudging the team.

Of course, the team are at liberty to consider other information. However, this should just be for the team to interpret and make use of.

Even these three measures could lead to misjudgement. Therefore I suggest leaders spend time with the team to understand the insights and stories behind these measures, and be aware of how such measures can be misinterpreted.

Trading-off the emphasises

There’s a trade-off between the emphasises of building the right outcome, building it fast, and building the thing right. Leaders should work closely with the team to ensure these trade-offs are appropriately balanced.

The balance should reflect the current and future state of product/service/process development.

However…..

…..conversations and co-creation are better than managing by measurements

Consider what Einstein is attributed to have said:

Not everything that can be counted counts and not everything that counts can be counted

If leaders only use measurements to judge a team’s effectiveness, there’s a temptation to manage the team indirectly. There’s also a dangerous possibility of misjudging the team.

Ideally, the managers should create a structure and set of processes which allows leaders to have meaningful conversations with the team. Leaders should involve themselves with the team to co-create and co-discover the best outcomes for their customers/clients/stakeholders.

Such an environment will outcompete any alternative where the leaders manage indirectly, provide little direct support and manage by measurements alone.

If measurements are being considered, leaders and the team should discuss and agree on the intention behind for measurements. It’s likely unintended behaviours and incentives will emerge, so with the team, measurements and its impact should be reviewed periodically.

When it an outcome achieved?

Agendashift’s Definitions of Done helps teams focus, and gain support from their leaders, to deliver genuine business outcomes.

An outcome is not achieved if it’s at a stage before users/clients/stakeholders are demonstrably benefiting from it.

Further reading and thanks

Feedback is welcome.

RUDE – Estimate more than team effort

RUDE is a handy mnemonic for estimating the work needed to deliver its intended outcome(s).

It stands for Risks, Uncertainties, Dependencies, Effort.

It reminds teams that when estimating work, they need to consider more than the effort needed to deliver the work.

FACTOR DESCRIPTION
Risks Consider the likelihood and impact of known aspects that, if they come true, will threaten the work or its outcome(s). Such aspects can be managed.
Uncertainties What unknowns could there be?
How unfamiliar is this work?
Amongst stakeholders, how acceptable is the work and its outcome(s)?
Early in the project, such factors are likely to be unpredictable.
Dependencies Who, and what, is the team depend upon to deliver the outcome(s). The greater the dependencies the greater the complexity.
Effort Estimated time and energy needed by the team to deliver the outcome(s).

This is separate from the effort of other parties who are needed to deliver the outcome(s), but should include the team’s effort to liaise with those parties.

Sizing work items

Teams may want to use Fibonacci estimation to size work items relevant to each other.

Note that two work items may be of the same size for different reasons.

For example, a work item may need little team effort but have high dependencies, whereas another work item – of the same size – may need lots of team effort but have no dependencies beyond the team.

Example – Project to build a house extension

The Goal

Your family would like a house extension built. Consider the family as the project team.

Risks

There could be known aspects which threaten the extension. For example, it may be known that it needs to be built on land prone to subsidence.

Uncertainties

This might be the first time the family is having a house extension built. So, for them, there are many unknowns.

The extension’s design will be subject to the agreement of local authorities, building regulations and your neighbours’ consent. Consider these parties as stakeholders.

Regarding the work itself, you may need to gain permission to access your neighbour’s land.

At the start of the project, stakeholders’ responses are likely to be unpredictable.

Dependencies

What specialists are needed to build a house extension? Has your team and the various specialists worked together before?

Effort

How much time and energy do you and your family estimate will be needed to manage the house extension project?

Related reading

Risk vs Uncertainty in Project Management