product build cycle – My musings

08 develop

product build and delivery

software development

At this stage we have a fair idea about the problem we are solving, we have prioritised the pain areas we want to target first and we have ideated what a potential solution could look like. Now, time to get on with what we want to build.

01 story mapping

In one of the previous steps we have created User Experience Map. That is a tool to understand the existing behaviour of the users

Now we are trying to build a solution to the problems they face and Story Mapping is a way to visualise how the user will interact with the product or service we are building. A user story map is fundamentally a depiction of the user’s high level interactions, on the Y Axis and refining them with detailed activities on the X-Axis.

Below is a simple illustration of how a basic story map for a Online Shopping Experience might look like.

The steps how we go about story mapping in brief incase you wanna get a gist of what it is about. Note there are at a high level two different ways of going about it and I have tried to capture one, assuming we have a high level prototype from the previous step.

I highly recommend watching this video. Though please remember that lots of organisations have their variations of how this is done and over the years we have found ways to improve this process as well. This is a good video to explain a lot of basic concepts but remember there are variations in how these steps are done by different people.

02 slicing and goals to deliver value

My personal experience:

I am gonna use a few terms through the rest of the passage and would clarify them in case they are something you are not used to – Slice/Slicing, Iteration, Goal and Value
A Slice – If we consider the whole product as a big piece of value for the user, a slice would be a logical piece of that value which can be delivered within a minimum optimum time period. For example some slices in the online e-commerce portal could be – product search, checkout experience, payment, shipping etc. If you are working on a backend engine kind of project a slice could be delivering the Web Service with monitoring, dashboards, logging, alerts etc
Iteration – is a time-boxed period of time where we want to achieve one or more than one goal as a team. Commonly this time boxed period could be 1-3 weeks.
A Goal – is a lighthouse for the team that keeps the team focused. An example of a goal for the team could be ‘enable the user to update personal settings through user profile’. Now, once the team have defined this as a goal for that iteration, we can work towards identifying the user stories and tasks that will enable us to achieve it. This helps the team prioritise and focus on what they would like to work on during that iteration. A goal or a collection of goals must deliver a customer value end of the iteration.
Value – is something that an end user can actually use. A user can be the end user or a technical user as well. Technical user could be another team consuming the API/service we are building, for example.
The guiding principle would be that after an iteration one or more goals related to a prioritised slice have been delivered and the user is actually able to use what has been delivered – not just delivering the UI or the backend, as far as possible. There might be cases where it is not always possible but if we make it a habit to think through we are able to do it most of the times.
One of the things that I would like to stress is that we want to also capture if there is scope to collect feedback from the value we just delivered, we may want to capture that as well so we can feed that back into product improvement.
I want to clarify that to me slice is not EPIC. Slices and goals are logical bits that help prioritise at multiple levels. Product –> Slices –> Goals. User stories, EPICs and tasks as delivery mechanisms that capture what needs to be done and delivered they can again be prioritised thus giving us more flexibility to prioritise.

03 prioritising

Jeff Patton, has explained it quite well in the video. After the story map has been done. This is where we now prioritise what we need to deliver and which priority. A principle that I have found useful in my experience in the past:

workout what is the bare minimum we can develop so we can start testing our hypothesis and the product experience or anything else that we want to get feedback on

04 visualising your work

A very common way of visualising your work is to use a kanban board. I am using the term kanban board very loosely. If we search for sample kanban board, we will find a lot of examples and the reason for that is that there is no fixed way to do it.

now if we accept that the primary goal of a agile team is to deliver working software which in turn means customer value, then obviously one of the most important things we want to measure is how is the value creation progressing or flowing through our systems. Now, the below picture is mostly for illustrative purposes which demonstrates one of the simplest of kanban boards

I am a bit old school with a few things and I still love my physical board more than the digital board. And yes I have encouraged my teams to maintain both as much as we possibly can.

so, what do I want to see on my Kanban board? My principle is: anything that is a problem that I want to visualise and monitor so we can improve/solve?

If we we look at different boards we will see teams visualising a lot of different things on the kanban board: Upcoming holidays, trainings, incoming support tickets, status of their alerts and dashboards .. so there are a lot of things teams monitor which they think will help them in managing and monitoring their deliverables.

The book below is a easy reading book and tells us a lot about how we can be more effective and efficient with the kanban board. Especially focussing a lot on WIP (work in progress)

05 measuring your flow

“Flow is the movement of customer value throughout the product development system. Kanban optimizes flow by improving the overall efficiency, effectiveness, and predictability of a process.”

(Daniel Vacanti, The Kanban Guide for Scrum Teams)

For all practical purposes the value flows through a kanban board in an agile team encapsulated in user stories or tasks. So, it is natural that we would like to measure how fast or nicely the cards are flowing through the various stages.

Why measure? Well if we don’t measure how we are doing – how do we improve? Or know if we have a problem ? I am not a great proponent of measuring a million metrics but probably measure only those that would be effective in helping us improve.

For some of us who have experienced working in Scrum, we might be very used to measuring Velocity, Sprint burn down charts, Product burndown charts etc. While those metrics have their own place and are useful, I personally have used the below more and have found them quite effective:

Cycle Time
Throughput
WIP