analysis – Joe Blogs

But why no technical stories?

In my current workplace we’ve been using User Stories in various guises for a while now. One of the things that frequently crops up is whether these Stories can or should be technical or not?

To start with it may be useful to remind ourselves of some of the aspects of a user story…

A User Story describes something that a user needs to do, and the reason they need to do this. They are always written from a user’s point of view, so that they represent some value to the user, rather than a technical deliverable.

They represent the who, what and why – an example might be –

As an expectant parent
I want to receive emails about parenting
So that I can read information about how to best care for my child

They are intentionally brief, so as to encourage further conversation, during which the needs of the user can be explored further, and potential solutions discussed. They are not intended to be detailed up-front specifications – the detail comes out of the conversations.

So who owns the User Stories?

User stories are designed to represent a user need. Most of the time these users are members of the public, but we don’t have our actual users in the office writing and prioritising stories, so we have a proxy for them instead – which we call the Product Lead (PL).

Part of the PL’s job is to represent what our users need – they use User Stories to capture these needs, ready for future discussion. So the PL owns the stories and their relative priority. If this is the case, then the PL needs to understand the stories, so that they can own them. If the backlog has technical stories in it, then it is difficult for them to prioritise these against other user needs.

For example, if the PL sees a story about enabling the public to search for GPs, and another story about reconfiguring a data access layer – they’re likely to prioritise the user-focussed story as they can see the tangible benefit. The technical work is totally valid, but it needs to be derived from a User Story – everything should start with a user need.

What if it’s an internal user?

As suggested above – most of the time the users we are capturing the needs of, are members of the public. Sometimes we use more specific personas in order to capture the needs of specific groups of people e.g. expectant parents

Other times, the users are our own internal users. We can still express their needs in terms of a user story –

As a data manager in the Data Workstream
I want to configure search results views
So that I can change the information displayed in accordance with DH policy

Here there is still an underlying need of the public, but the story is expressed from the point of view of the Data Manager. We could have just written down a technical story like –

Build a data configuration system for results views

but if we do this we have skipped a step. We have assumed that we know the single best solution straight away. Maybe there are other options to achieve their initial need – maybe if we stop to think about these other options we will find one that is cheaper/better/faster too.

When should we do technical design?

Although we need to some technical design up-front in order to set a general direction of travel, the detailed design work for a particular story should be done as close to actually implementing the story as possible.

In the past we have suffered from doing lots of detailed design of technical implementation well in advance of actually being ready to deliver that piece of work. Often by the time it came to deliver that piece of work our understanding had evolved and the up-front design was no longer valid.

Don’t try to do the technical design work when you first create the story. Wait until we are ready to deliver that story, and then look at the technical options available. By doing this work Just-In-Time we are much less likely to waste effort thinking about a solution that will never be delivered.

How do we track progress?

We track progress in terms of completed stories. If we keep those as User Stories then we are measuring our progress in terms of actual value delivered to our users.

If we break stories down into lots of technical stories then it may look like we are making lots of progress, and that we are very busy, but we could have delivered very little genuine value at the end of it all. If, for example we reported that –

“We’ve completed 90% of the business layer code”

that sounds very positive, but we could have delivered no actual working tested functionality for our users at this point. By keeping our stories user-focussed, our progress is also measured in terms of value delivered to users.

How do we get from User stories to technical scope

We’ve talked about how important it is to start with user needs, but ultimately we need to build something, so we have to get down to the technical detail at some point.

One way of ensuring that all scope maps back to an overall goal is to use a technique called Impact Mapping. We used this on a very technical project to ensure that all of the technical deliverables mapped back to an overall goal.

At the same time as deriving those initial stories, we’d usually be thinking about the overall technical approach. We’d look for answers to high-level questions around what technologies to use, and what approach to use. These wouldn’t be technical stories though – this would likely be documented in a lightweight high-level design document.

Story Decomposition and Technical Tasks

Once we’ve derived some initial user stories from our goal, we’d continue to break those stories down until we arrive at the technical scope.

User stories can be split into smaller stories but we always try to retain value to the user in each story, rather than making them technical.

For example, the story above about parenting emails might be split into smaller stories like –

As an expectant parent
I want to sign up for email notifications
So that I receive useful information about caring for my baby

As an expectant parent
I want my email address to be validated
So that it is clear when I have entered an invalid email address

As an expectant parent
I want to provide my first name when signing up
So that the emails I receive are personally addressed to me

Each of these stories is a smaller deliverable, but still makes sense from a user’s point of view.

Further to that, once we end up with nice small stories, we can create a list of technical tasks. Each story might contain the tasks needed to deliver that particular story. The tasks get down to the level of technical detail around what components and packages need to be altered, in order to deliver.

Ultimately – we will end up with technical pieces of work to do. Key is that all of these are derived from user needs.

* We don’t have to use User Stories for EVERYTHING

Okay, so we go on about User Stories a lot, but ultimately they’re just a tool for communication. A User Story represents some change we want to make in order to deliver some value. It’s a cue to go and have a further conversation about that piece of work, and that value.

If we can have these conversations, and deliver the value, without writing stories every time, then maybe that’s okay. The most important thing is for the people concerned to talk to each other frequently, deliver the work in really small chunks, and get feedback as often as possible.

User stories do really help us with this, but there might be occasions when they’re not the best tool…

Conclusions

Yes, we’re going to end up with stories that are technical in their implementation, but it’s important to not jump straight into that implementation. Think about our users, and their behaviours – and derive the stories from that.

Impact Mapping on ODS

Impact Mapping is a technique for deriving scope from goals. It’s useful for looking at different options for meeting a particular measurable goal.

I’d been keen to try impact-mapping-cover it out since picking up a copy of Gojko’s book on the subject at BDDX2012. I don’t think we’ve used it ‘end-to-end’ yet – to truly evaluate and measure different options – but I have found it really useful in deriving scope and ensuring that scope maps back to an original goal.

A good example of where we used Impact Mapping to derive User Stories on a very technical project was the ODS migration project. Due to the restructure of the NHS – removal of SHAs and PCTs, and introduction of CCGs and ATs – we had to do some work in order to reflect this structure to the public.

This involved extensive changes to multiple ETL packages, and changes to the code to generate organisation profiles. We could easily have dived straight in to the technical detail and decided which ETL packages to change.

Instead we went through an exercise to ensure that all of the technical work we were to undertake was mapped right back to the overall goal.

1. Goal

Firstly we established the overall goal that we’re working towards. In this case the goal is for the nhs.uk site to accurately reflect the new NHS organisation structure.

Normally with this technique we’d want the goal to be measurable – like an increase in profit of 5%, or an increase of 10000 subscribers. In this case the goal is effectively binary – either the site does reflect the new structure, or it doesn’t…

This is the cell at the centre of the map.

* In hindsight maybe we could have been more rigorous with the goal and measured it by surveying site visitors as to their understanding of the new structures. This may have been a better measure of the true overall goal – which is to communicate the new structure.

2. Actors

Next we went through an exercise of mapping out the different users, or actors associated with the goal of reflecting the new NHS structure, for example –

The external organisations who provide data feeds into nhs.uk – ODS, PPD, EDOS, PCIS
Organisation profile content managers
The general public themselves, as they are going to view the new organisation profiles on the site.

The actors are represented by the pink cells surrounding the goal. ‘Big Shots’ is a role that my colleague Ashish came up with – the senior stakeholders who use the accountability views in our ‘Find & Compare’ product.

In future I’d like to identify more specific roles, and possibly tie them in with the personas that our UX team use.

3. Impacts

After identifying these different roles, we looked at the different ways in which they contribute to reflecting the new NHS structure, or how their behaviour will change as a result of the new structures. What are the impacts we want to have on the actors, or the impacts that we need the actors to make.

The blue cells represent the impact. The map really starts to expand at this point as some roles can do many things to bring us towards our goal.

4. Scope

Once we’d identified all of these behaviours we could then start to derive the scope required to enable that behaviour to occur.

So for example – ODS provide a nightly feed of the new NHS organisations, this is how they contribute to our goal of reflecting the new NHS structure. The work we need to do to enable that is to create a series of nightly import and data-synchronisation processes.

These can be derived as a series of user stories – something like

In order that nhs.uk can reflect the new NHS organisational structure
ODS can provide a nightly feed of CCG data

Each story is represented by a green cell. The overall map looks like this –

Some of these stories were high-level and were then broken down further – we just added another level of nesting of green cells to represent this break-down.

Visualising the backlog

I’ve found the map a really useful alternative way of presenting the product backlog for a particular project or piece of work.

Since we started using User Stories to represent requirements, some have commented that in doing so we lose sight of the bigger picture.

One thing a colleague mentioned the other day is that User Stories are like leaves on a tree, but when we put them into the backlog it’s like stuffing all the leaves into a bin bag – making it pretty difficult to maintain any context between them.

Now with our Impact Map we’ve re-formed the tree with the leaves in place. We can stick our map up on the wall, and cross items off as they’re completed, or make notes against them.

Living Document

We had a good stab at capturing the necessary scope up-front, but naturally things emerged as we progressed with the work. Having this Impact Map meant that we could always check where suggested scope fitted into the big picture – how did it help us get towards our goal.

“Does it help us meet the goal?”

Some technical work was suggested around changing the mechanism by which we import certain data feeds, but when we examined it in the context of the map, it turned out we didn’t really need to do it. If we had jumped straight into the technical work without looking at the users, their needs and impacts, we would have wasted time doing this unnecessary work.

Tracking

I was acting as BA on this project, and I personally found the map a really useful way of tracking scope, progress towards our goal, and what our priorities were. The map itself was useful during planning, prioritisation and design sessions, as we had a visual representation of the scope in front of us.

Each green ‘scope’ cell was set up to link to our work tracking system, and it was easy to visually represent progress on the map by ticking off or shading the completed stories. This showed how much closer we were getting to our overall goal.

The map was also used to show up blockers and dependencies in scope. We used icons in Freemind to indicate key questions and blockers that arose during delivery.

Tools

For the map described in this post I used FreeMind. Once you have a few keyboard short-cuts set up it’s quick to colour-code the cells and add icons and hyperlinks in.

I also tried out a MindMup version too.

Next steps…

The big thing I felt was missing from this first attempt at Impact Mapping was making the goal measurable. When I first created the map I didn’t think there was much in the way of metrics that we could use to measure our progress towards the goal – there’s certainly not a monetary value from our point of view. We could look at measuring the amount of traffic that certain areas of the site receive before and after implementation, and we could measure the number of service desk calls we receive in relation to the NHS structural changes.

This is something we need to work on – tying the features we deliver back to explicit, measurable goals. I think it really helps the whole delivery team understand what we’re aiming for, and if we can keep our options open for meeting that goal, and measure our progress towards it, then all the better.

We’ll keep refining our use of this technique on further product developments. We’ll push to get the Impact Map created as early on as possible, when we’re still figuring out the overall goal.