Archive for the ‘Guides’ Category

Strategy

VMOST = Vision, Missions, Objectives, Strategies and Tactics

Each product should have a clearly defined product vision, KPIs and strategies if it’s expected for the development team to deliver outcomes/head in the right direction and using the VMOST canvas is an effective way of showcasing what these are in a clear and concise format.

VMOST example

Vision: A passionate and exciting statement which typically should only be one sentence, where in a nutshell it should explain what your ambition is/what is your end goal of the product and who it’s for. More info on creating a compelling product vision can be found here.

Missions: In order to achieve the product vision, there would be multiple high-level missions you need to go on – what are the biggest problems which need solving before achieving the vision.

Objectives (KPIs): You can track progress of your missions through setting multiple objectives (aka KPIs), which would include metrics which are measurable.

Strategies: Initiatives which would deliver/impact the objectives (KPIs).

Tactics: Multiple ideas (Epics) which would deliver each strategy. The tactics should be laid out on the product roadmap, so there’s a nice link between the product VMOST and product roadmap.

Although the product owner is responsible for defining and owning the product VMOST, it’s important that it doesn’t happen in silo, as it takes collaboration with the rest of the business especially stakeholders/data/customers to help provide some guidance on the selection of problems to solve which would be represented on the VMOST.

Once the VMOST is ready, it’s time for the product owner to showcase this in a passionate way across the business and perhaps print it out on A0 to sit near the scrum team on the wall, so it can always be top of mind.

Good luck in creating your VMOST!!

Less

LeSS (Large Scale Scrum) is an agile framework for 3-8 Scrum teams, but when there’s more than 8 Scrum teams it’s time to think about adopting LeSS Huge. So let’s look at the differences.

LeSS
LeSS is a scaled up version of one-team Scrum, and it maintains many of the practices and ideas of one-team Scrum. In LeSS, you will find:

In LeSS all Teams are in a common sprint to deliver a common shippable product, every sprint.

LeSS Huge

Less-huge

What’s the same as the smaller LeSS Framework:

  • One (overall) Product Backlog
  • One Definition of Done
  • One Definition of Ready
  • One (overall) Product Owner
  • One Sprint

So what’s Different?

  • Area Product Owners
  • Area Product Backlogs
  • Area Product Vision
  • Set of parallel meetings per Area

It’s important to remember that these frameworks are just guides and every business has their own org structure, so it’s completely acceptable to mould a framework to suit the organisational structure and industry sector.

Pipeline

With a long list of ideas / problems (features) to solve, there needs to be a solid view of exactly where features are in the idea to customer flow, so that anyone can view the status of a feature anytime without constantly asking.

Having a ‘feature pipeline’ report also proves helpful when providing stakeholder monthly / quarterly product updates.

A feature pipeline typically has multiple columns similar to a Kanban view, but it’s important to keep the content at a high- level (feature / epic) rather than stories.

Pipeline

Example Feature Pipeline Format

Some of the columns you’d have on a Feature Pipeline would be:

  1. ‘Idea’: which would be a long list of features sorted by value
  2. To Be T-Shirt Sized‘ (WIP 5): top 5 highest value features move over to a sizing column – in order for the idea to be prioritised on the product roadmap you need a rough size. It’s recommended to have a WIP (work in progress) limit
  3. Capacity Planning‘: once the feature has been roughly sized, it’s then possible to analyse when the feature can be worked on based on capacity and priority (value vs. effort (t-shirt size))
  4. Delivery Quarter‘: based on the capacity planner which should drive the start and end dates of features on the product roadmap, what quarter does the feature planned to be delivered in

There are plenty of tools available to visualise your feature pipeline eg. Aha! and JIRA and it’s a good idea to compliment that with a guide which includes SLAs for each stage of the pipeline and a t-shirt size mapping, so it’s clear what a ‘Small’ or ‘Large’ is for example.

Having a Feature Pipeline in your product toolkit for everyone to access when they want will help ensure that high priority ideas get to customers in a timely and transparent way.

Gap analysis

A Product Owner creating and maintaining documentation for new and existing features is just as important as those who maintain documentation in other roles especially developers.

Whether you use Confluence or other documentation software, having documentation makes it easy to provide context and clarity around the importance of getting after a particular feature whether it’s to the development teams or stakeholders.

When a new feature / problem / idea has cropped up, it becomes very useful to start documenting elements before any development effort is spent creating user stories or getting Product Backlog Items (PBIs) in a ‘ready‘ state. The key elements being:

  • One line description about what the feature is
  • Tagging in contacts eg. Product Owner, Technical Architect, Scrum Master, Stakeholders etc
  • Problem / Value including metrics / data
  • High-level requirements
  • As Is‘ and ‘To Be‘ flows which indicates where the gaps are
  • Competitor analysis if relevant
  • Actions / Next Steps
  • Technical details
  • Identifying and Tagging in dependencies

Having ‘As Is’ (Current State) and ‘To Be’ (Desired State) flows is a great way of clearly identifying where the gaps are, where you need to get to, what your competitors are doing in addition and what you need to do to get to your desired state. Having requirements visualised in this way also provides clarity of what you’re looking to achieve and becomes an easy way to digest and collaborate on the requirements vs. a long list of written requirements.

Spending time documenting the analysis of the idea / problem will help get the idea to a customer as efficiently as possible, providing clarity to the stakeholders and developers as to the ‘what‘ and ‘why‘.

With facilitating processes and tasks at the heart of the Scrum Master role, it requires someone with a proactive, helpful, motivated, can do, kind, organised and supportive mindset in order for requirements to be solved in an efficient way in the right priority order.

With the Product Owner, Developers, QAs, Technical Architect and Stakeholders all focused on getting their job done where there are clear boundaries, it needs someone to fill any missing gaps or connect them together in order to get the job done, which is where the Scrum Master comes in.

Let’s look at a day in the life of a Scrum Master:

Scrum master

Done

Once the product backlog is in a good quality condition and the product backlog items (PBIs) start moving into development, there’s a significant amount of tasks to tick off before the feature can be marked as ‘done’.

Typically a development team would use a ‘definition of done’ (DoD) as a reference to ensure that none of the processes get missed off before it’s ‘done’, as each of those processes are essential and could have considerable consequences for the business and customers if it’s not done.

Some examples of what could be in a definition of done:

  • Code is reviewed by someone who didn’t do the PBI
  • Code is deployed to test environment
  • Feature is tested against acceptance criteria
  • Feature passes regression testing
  • Feature passes smoke test
  • Feature is documented
  • Feature has analytics tracking
  • Feature approved by UX designer / stakeholder
  • Feature approved by Product Owner

Missing any of the DoD processes before a feature gets delivered to a customer could result in critical bugs across the feature, causing bugs across other features in the code, bring down the product or delivering the wrong requirement, so it’s essential to take the definition of done seriously even if it means taking the PBI over to the next sprint resulting in potentially not meeting a sprint goal.

Once you’ve created a solid Product Vision, it’s likely you’ll be asked to provide more granular details on the ‘what’ and ‘when’ and the Product Roadmap is a great way of helping you answer that.

The product roadmap is also a good way of giving the development teams an idea of the exciting upcoming features / problems to solve for the product.

Key points of a Product Roadmap:

  • It should be at a high level eg. Epic, feature or iteration level – Epic level is a preference as then it maps nicely to the product backlog items (PBI)
  • It needs to include dates spanning the next twelve months whether monthly or quarterly
  • The bars on the chart show when items start and when the development will be complete (live hidden)
  • One of the most important things is to educate development teams and stakeholders that the drop dates are an intent (not commitment) of focus / delivery and that things can and will likely change, so it’s advisable to avoid spending significant amounts of time making each item exact, as the desire from the business would be to have a rough idea of the twelve month view rather than knowing whether something starting in six months time will be delivered exactly a month later than that for example
  • The roadmap needs to be easily accessible by anyone in the business where they can use their network login and can also access it from outside the office eg. on the train – if it’s hard to access, people just won’t view it and assume there’s no plan
  • It needs to be updated frequently – if it’s regularly out of date, again people just won’t access it

Product Roadmap examples

Roadmap sample 1

Roadmap sample 2

The most important thing about the Product Roadmap is to always provide a sign of intent for when product items will be delivered over the next twelve months, with the key word being ‘intent’ here ie. Not exact drop dead delivery date and a couple of people with experience of productivity could use gut feel which is totally acceptable, rather than dragging developers away for days on end to roughly size big pieces of work which will either 1. Change anyway and 2. Be extremely inaccurate as unknowns result in estimates going through the roof.

A sign of intent for the next twelve months for the product is also better than a half empty roadmap!