We and our partners use cookies to provide a secure site, personalise content and tailor or measure ads. By continuing to use AO Consulting, you agree to the use of cookies.

Visual Release Roadmap

Whilst working with a new team, I always want to know the bigger picture. I want to understand the problems we are looking to solve. What steps we taking to realise the vision or solve the problem. How we are visualising and socialising these steps. How we plan to measure success. Not talking about the 2 -3 year grand plan but the level below that. Not your long list of epic’s either, more closely related to Minimum Viable Product, thinking more about themed features (a group of closely related stories that contribute to a goal).  One way I have achieved this is by using visual Delivery Roadmap .A 3-6 months strategic Delivery Roadmap created by the Product Development Team .

Delivery Roadmaps help in communicating what goals are important to your delivery and when the team aim to deliver it. Some call It an explicit battle plan for the team. I want to know as a team member (Management or Development) that I can ensure everything I’m doing brings the vision one step closer. If I’m external to the team, I can see your vision and high level steps you are taking to reach you goal. If I am asking you to work on other stuff you can show me immediately what will be impacted. I can visually see possible dependencies between Themes or dependencies externally. Development efforts need to center around the delivery of business value. The Product team should aim to articulate and radiate what value is top priority.

Planning Is Everything. The Plan Is Nothing. The process of coming together to develop a Delivery Roadmap encourages a shared vision. I prefer running workshops to ensure a consensus on direction. The thinking process before an initial Delivery Roadmap  is developed is where you find value, so not necessary the plan itself. The plan is the artefact that records what’s been agreed. A Delivery Roadmap  should not be a precision planning tool as detailed planning is achieved at backlog or iteration level.

However, once a colleague took it a little far by not estimating the Themes with the team. It causes all sorts of issues. Before new Themes go on your Delivery Roadmap , it is good practice to involve other team members who will be committing time to delivery (Testers, Business Analyst, Developers and/or Architects).  Getting estimates on a plan isn’t a new thing but the approach on Agile projects at this level is not to get lost with precision. Generally I want to know the t-shirt size (S,M,L) of the Themes from discussing the possible stories that will make MVP (noting that things ALWAYS change ).  In Agile Projects we “Responding to change over following a plan” , this means once we get into the details and know more about the work in relation to team capacity and business climate, we should replan. The team needs to be the master of their destiny and frankly if I was to commit to something I would want to at least give myself a good shot of getting close enough. I hate working on a plan that was laid out for me without my input and I wouldn’t do this to another professional. The team needs to buy in.

So who takes ownership for this artefact? Well, when I first started this practice I tasked the whole Product development team with updating it. What a massive failure.  Long story short, after an initial workshop with key specialist from the team and extended team, I keep the Delivery Roadmap  updated with product managers, business analyst and Scrum Masters on the team. I ensure it is, updated on every planning cycle with planned and actuals. The Delivery Roadmap  is played back to the team at planning intervals. Usually I do this before we commence Sprint or Iteration planning and during Backlog refinement. The aim here is to ensure we are focused and we are working up to the agreed vision.

A lot of product/software teams miss opportunities to communicate their vision in this way, where they are going and what it will involve to get there.  It is a very useful communication tool when talking to people high up in the organisation, it will help to solicit feedback and validate direction.  It’s  also about keeping the team on track and focused on the bigger picture. As a company grows, it becomes more important for a product teams to articulate what’s happening now, what’s next and what’s to come. Cuts out wasting time on what’s not important.

More Stories
Why Projects Go Wrong or Fail