Visualise an agile product vision

The approach I am advocating is suited to when you want to look at a single agile product vision. It allows the product to be managed in an agile way, whilst providing the teams and stakeholders a single reference point that visualises both priorities and progress.

The board should be in a position that is permanently highly visible, with space around for people to conduct periodic reviews.

The layout of the Board

Display the product vision

So that everyone associated with the product understands the product vision, it is essential it is kept visible. If the vision is just mentioned at the kick off and then only exists on wiki pages or in documents sitting in a shared folder, it will not be used so put the vision up on the board as a constant reminder of the purpose of the product.

Display the objectives

Put up a swim lane for each of the product objectives. The work is going to be organised by objective, not by team, and so will need a swim lane dedicated to each objective. I like to ‘bookend’ the swim lane by having a card, with the objective written clearly, at each end of the swim lane. This will be useful later when the objectives have been completed.

Order the objectives

Put your objectives in order, taking into consideration both urgency and importance. If you are struggling to do this then don’t just press on with the product. Spend a day or so to review with stakeholders and decide the order. Ultimately it is the person in the Executive role who should have the final say on this, but this should be done after a healthy dialogue with those who have an interest. Periodic review is essential to agile processes and the objectives could be reordered as part of a review.

On the board, order the objectives from top to bottom with the primary objective at the top of the board.

Set your review period

Having a clear review period for the product vision is useful because:

  • it allows the teams to forecast up to this period;
  • it manages the stakeholders’ expectations in terms of what may be achievable in the given timescale;
  • it presents an opportunity to review the objectives, including their order, and for the product vision to respond to any external changes such as market conditions or overall business goals.

Populating the board

The next stage is to start populating the board. The level of detail I am advocating for this is high level stories. As is common practice, I have used the term ‘Epic’ to indicate a high level story that will be sliced into smaller stories as the team approach doing the work. I suggest using one card per epic per team.

Populating programme board

Indicate which team will be doing the work

When writing the cards indicate which team will be doing the work. I have used different colour cards for this, but you could put labels or icons on the cards.

Clearly indicating the team helps members of that team identify their contribution to the overall product.

Put the team epics against the objectives to which they relate

Rather than having a section for each team, put the epics on the board in the swim lane for the objective to which they relate.

Forecast based on order of the objectives

Starting with the top objective, the team forecasts how many of the relevant epics they can complete within the time period, putting them in the ‘current’ column and leaving the remainder in the ‘future’ column. They then move down the board adding in the epics they forecast they will be able to complete that are associated with the other objectives, taking into account the epics higher on the board in the ‘current’ column. The team will eventually get to the point they feel that they will not be able to complete any more epics within the time period.

On the above example board, team 2 cannot include epics 4 and 5 in the current time period as they are already looking to complete their epics 1, 2 and 3 in that period.

Indicate which objectives will not be progressed

Once all teams have completed this process, there are likely to be some objectives that cannot be started. Make this visual by moving the objective card over to the end of the current period so that all of the epic cards are in the ‘future’ column.

Reviewing the product vision board

As stated above, periodic reviews of the product and product vision board are essential, so the product vision can respond to new information that comes in. Doing this at regular intervals gives this process structure. However, there may be occasions when the circumstances have changed significantly and waiting for the next planned review is not desirable.

Programme board further developed

The following activities should be done during each review.

Remind the attendees of the product vision

Making sure the attendees who are reviewing the product vision board understand the product vision. It may well help the discussions as the work should all build toward this vision. If the vision has been fulfilled, it may be time to close the development, even if not all objectives have been met.

Move all of the completed epics into ‘Done’

Add a ‘Done’ column to the left-hand side of the board. I realise it is a little unconventional to have it on the left, but in my view, it works better this way with this kind of board. A card should only be moved into ‘done’ when all work associated with that card is complete.

Confirm objectives and the order of the objectives

As with any agile process, the team or teams delivering it learn as they go. There could also be external factors that have changed. Sticking rigidly to the objectives that were set and ordered at the beginning of the product regardless of this new information does not seem like the right thing to do. We must be prepared to reconsider the objectives and/or the order of the objectives to ensure they are still relevant to the product vision.

Identify any additional epics that are required

As teams progress, additional work may become evident that is necessary to achieve the objectives. These are added to the board as additional cards. It is also possible some epics that were previously written on one card, can be divided into multiple smaller epics and have their own cards.

Populate the ‘Current’ column

Teams should now populate the ‘Current’ column based on their forecast for the next period. This takes into account what was delivered in the previous period and any new cards that have been added. As before, teams should work their way down the board.

Indicated objectives that are expected to complete

If any of the objectives have no epics in the ‘Future’ column, and no further work for that objective is anticipated, then move the objective card on the right of the board to the beginning of the ‘Future’ column to indicate that the objective is forecast to complete at, or before, the end of the current period.

Indicated objectives that have been achieved

If an objective has been achieved, then this can be shown by moving the objective card from the right of the board to the beginning of the ‘Current’ column. This indicates there is no further work necessary to complete this objective.

Things to avoid

When adopting this approach to visualise an agile product it may be easy to introduce some command-and-control behaviours so here are a few things to look out for.

This is not a Gantt Chart or a roadmap

Don’t turn this into a Gantt Chart by adding in dependency arrows or into a roadmap by forecasting beyond the current period. Each product should have its own roadmap where the future epics may appear. This should be visible to those interested and it is unnecessary, and potentially an administrative overhead, to look to replicate that roadmap on the product vision board.

This does not replace the need for team level events (Sprint Planning, etc.)

The team should continue to follow their own processes. The product vision may or may not be the only source of work for the teams but even if it is, the team should still hold all of their events.

This does not overrule the Product Owner

There could be many reasons why there is a different point of view between the Product Owner and the product leadership. Hopefully, this can be resolved through constructive dialogue but, until this happens, the team involved must use the sequence provided by their Product Owner and not by any other stakeholder.

Summary

  • I am advocating this approach as a way to visualise a single agile product vision.
  • A clear product vision and ordered product objectives are required in order to create a product vision board in this way.
  • The board should be in a position that is permanently highly visible.
  • Periodic reviews around the board will help stakeholders understand progress but also give the product vision a structure when it can respond to new information or changing conditions.
  • This visualisation does not replace team processes but is a light touch addition designed to complement individual team roadmaps and events.

Leave a Reply