Archive for the ‘Product Backlog’ Category

We’ve all been there. Someone describes a problem that they want solved (and possibly suggests how they think you should solve it) and in the very next breath asks: “So, how long will it take?”.

Invariably, we get talked into providing some kind of gut feel indication (days/weeks/months/quarters) based on nothing much besides (perhaps) experience. But how often in software do you actually do a rinse-and-repeat of something you’ve done before? In my 10 plus years in IT, never. Never ever.

Unfortunately, we don’t yet work in a world where most people are happy with “we’ll be done when we’re done” so a vague timeline is always needed: if only for coordinating training or the launch email and party. So where does one start?

For me, the first time you can possibly try get a feel for how long your horizon might be, is after you’ve shared the problem with the team and they have had a chance to bandy around some options for solutions. At this point, assuming your team has worked together before, you can try do some planning poker at an Epic level. Pick a “big thing” that the team recently worked on, allocate it a number (3 usually works) and then have the group size “this big thing” relative to the one they have previously completed. I prefer to use a completely random number (like 3) rather than the actual story points delivered for this exercise because otherwise the team might get tied up debating the actual points and not the gut feel relative size.

Now, if you have a known velocity and also know the points delivered for the big thing we already built, you should be able to calculate an approximate size for the new piece and use your velocity to find a date range with variance (don’t forget about that cone!). For example:
– If we agreed our “Bake a cake” epic was a 3
– And then sized the “Bake a wedding cake” epic as a 5
– And “Bake a cake” was about 150 points to deliver
– Then “Bake a wedding cake” is probably about 3/5*150 = 225 points to deliver
– Which means you’re probably in for 225/velocity sprints (with 50% variance)

At the very least, this should help you pin-point which year and perhaps even quarter this thing is likely to be delivered. (Don’t make any promises though – remember the cone!)

When we know more….

Now, if you’re doing things properly, your team will groom the big epic and slowly start agreeing on small to medium stories and perhaps even slices. Ideally you’ll have a story map. At some point, you should have a list of stories (or themes or whatever) that more-or-less cover the full solution that the team intends to build. At this point, it is possible to do some Affinity Estimation, which will give you another estimate of the total size (in points) relatively quickly that you can sanity check with the help of velocity against your previous guesstimate. If you’re working with a new team and haven’t got a velocity yet, this is also the time when you can try ‘guess’ your velocity by placing a couple of stories into two-week buckets based on whether the team feels that they can finish them or not. This article explains this process in a bit more detail.

Keep checking yourself…

You will probably find that when you do Affinity Estimation that you will still have some biggish stories in the list, which is OK. Over time as these break down, it’s probably a good idea to repeat the exercise (unless you’re so great at grooming that your entire backlog has already been sized using Planning Poker). Until you have sized everything in detail to ready stories, Affinity Estimation is the quickest way to determine a total remaining backlog size that is reasonably useful. Over time, if you maintain your burn-up, you’ll be able to track your progress and re-adjust plans as you go along.

Did you find this post useful? Have you used these techniques before? What other techniques have you used to try build a view of your release roadmap?

I really enjoyed the workshop on story mapping. Sadly, I still feel that although I ‘get it’ at a theoretical level, I still cannot see easy ways to use it in practice. It seems harder to create a map than it looks!

Suggested approach to creating your story map:

Create a vision (e.g. using the Business Model Canvas)

Write up the process or map (as described in the video). Think about the various user roles.

Explore the map with questions. “What if…?” “What about…”?

Group your activities to form a backbone. Focus on breadth and not depth. Consider the goals for your user personas.

Slice your activities into outcomes based on your persona goals.

Build your development strategy (order in which you will release)

Other notes

On average, you will usually identify about 15 user roles. These can usually be combined into about three user personas.

Unless you are working with a mature product in a stable environment, your road-map should be about delivering goals and not features.

When building your development strategy, it usually makes sense to build your high value, high risk items first.

“Refactoring is like tidying up at home. If every time I come back from a shopping or from a business trip, I sling down my things and don’t put them away, pretty soon my house is a mess. I can’t find anything, I may end up buying new items because I can’t find the ones I know I already have. It becomes more difficult to move around the house – there are piles of stuff everywhere! I may even break something because it’s obscured by other stuff on top of it.

Refactoring is the necessary act of putting code in the right place, where other developers can find it quickly and easily. It’s keeping code organised and decluttered. Developers need to do refactoring, or they can end up with the same code in several places, which takes more effort to maintain. Refactoring is not the aesthetic organisation of the code, such as applying feng shui to your home – it’s basic housekeeping.”

This week I stumbled across an article which referenced something called “Dual Track Scrum” (see the links below). Intrigued, I researched a little more and was fascinated to discover that there was a documented process/approach to product development and delivery that was very similar to what had evolved for a product team I previously worked with.

This isn’t the first time this has happened to me. The last significant deja vu experience was when I found that there was a name for a software development approach that included: time boxing; daily team check-ins; planning and estimation as a team; work defined on a physical card on a white board; a definition of done for the time box that included all delivery activities; and a list of features that could be traded in and out if not yet started. Yes, that was the day I discovered that the approach our team had “created” to successfully deliver an off-shore project was, actually, called Scrum.

As we were unable to finish the story-mapping process in a single session, we had a second session the following day. As prep and to save time, I asked the team to bring their top six user stories written on separate stickies. Following the approach outlined in the video, we grouped and prioritised their top stories and then I asked the team to pick their overall top five. At this point I also introduced the concept of tarred vs cobblestoned vs dirt roads (stories):

A dirt road is minimum implementation with manual workarounds; something that will be in place for a limited time span (throwaway)

A cobblestone road is a bare minimum implementation with foundations for a longer term solution

A tarred road is a complete implementation: a ‘done done’ story

Cobblestone and dirt road stories were written on an orange sticky, while tarred road stories were yellow. Even with this mechanism, the team were not able to get their first slice down to less than seven tarred stories – which was still great going 🙂 With our first slice agreed and our pink risks/issues added to the appropriate place on the map, we had just enough time to do a bucket estimation exercise. For this, I laid a set of planning poker cards on the floor to create buckets; picked a story as a baseline (I chose one we’d already implemented for more context); and then everyone had to add stories to the buckets according to where they thought they should go relative to the baseline. This is a mostly silent exercise. For the first part each person is given a random pile of stories to place into buckets. For the second part, everyone reviews and (silently) moves stickies to different buckets if they disagree with where they have been placed. If a stickie moves a lot, it is parked. When the stickies stop moving and stabilise in their buckets, then the parked stories are discussed to understand why there are differences in opinion and the team should then reach consensus on which bucket each parked story belongs to. We didn’t have to do this last part as everyone was more or less on the same page about where things belonged.

As an aside, after we’d created our map, I reviewed our completed work and added those stories into it as well. We will be tracking progress on our map as we go. It is recommended practice to write duplicate stickies for your taskboard and not leave gaps in your map. I can see this also making sense where a ‘map story’ may need to be broken down into smaller stories for sprint purposes (if your team is using Scrum). For us, a map story that is in progress gets a dot (sticker) and, once it’s done, we tick the dot. It’s visual and easy to follow.

After a total of three-and-a-half hours we had the following:

A better understanding of the short-term and long-term goals of the project.

A ‘first slice’ to test our architecture, resolve some technical challenges, and deliver some business value in production.

A first pass idea of the size of the full scope of work.

A picture view of all the above with a visual way of showing progress against the overall scope.

Things that I felt worked well in the second session:

As we don’t have a team room (so were using a shared meeting room), I did have a challenge with the session being split over two days as I needed a quick way to reproduce the map for the team for the second session. In the end, I took photos of the various sections and printed them out in colour and that was enough for the team to refer back to (helped by the fact that they had all rewritten their top six stories on stickies for the second session anyway).

The road analogy helped create a common understanding of the level of work we were targeting and using a different colour to represent work that was not ‘tarred’ made it clear where we would have to revisit items to fully complete the story.

Giving people a very strict limit initially. I doubt we would have ended up with a slice of seven stories had I not been so strict about trying to get the team to only pick five.

The sizing exercise got people off their feet and moving around (automatically creates more energy).

The sizing exercise took all of 15 minutes, so high value for small time investment.

Things that didn’t work well:

Some of the team members were unable to attend the second session. We decided to go ahead anyway, but this did impact the perceived value and accuracy of the sizes.

The team haven’t taken ownership of the story map (still perceived as ‘my thing’). Need to find a way to change that perception!

This article describes two techniques: Affinity Estimation and Bucket Estimation. I’ve used both before and I so far have found bucket estimation is quicker so better for large backlogs (value:time ratio for affinity estimation doesn’t seem as good).

I liked the idea of story-mapping from the first time that I read about it. I’d done a couple of up-front sprint zero type exercises to create and size a Product Backlog at my previous company, and the feedback from the team about the exercise was that, once it got down to the relative sizing, it was hard to keep a grasp on the bigger picture and people often got confused about the relationships and boundaries between stories.

Simply, a story map is a way of maintaining a visual connection between stories as it shows the higher level user process (which also intuitively maps dependencies in 99% of cases) while showing the stories underneath. The other cool thing is that it’s a visual way to ensure one is doing vertical slices – by choosing stories in horizontal groups (so across the user process). Stories are also prioritised vertically adding the dimension that comes from the traditional Product Backlog. One of my team members, seeing our story map for the first time, described it as a ‘seven dimensional view’ of the project. Amazingly, although it has these many dimensions, it’s a pretty simple view to understand and can also be used to show progress.

If you haven’t already done so, I recommend you spend a worthwhile hour watching this video. I’ve also added some other links about story-maps below, but the video is still one of the best resources I’ve come across.

For this two-part entry, I’ll describe a bit of how our very first story mapping session went and some of the learnings I gained from running it. I intend to do some follow-up posts over time as our map (hopefully) evolves.

Our ‘project’ is slightly challenging to story map as

We’ve already started working

It’s about replacing something that already exists

It’s related to our security architecture – so it’s very technical and quite difficult to map from a ‘user’ perspective.

My session (which ended up being two) followed the approach in the video quite closely, so had the following parts/steps:

An intro in which I highlighted the desired outcomes and high level process that we would be following in the session. I also introduced the goal that was proposed by the Product Owner. This led to some debate as it was more business focused, whereas work to date (about a year) had been more about the technology. The team felt there were other ways to achieve business value using the existing infrastructure (a valid point). In hindsight, the goal may not have been the best goal for the session, but it did result in some much-needed debate and clarification and still helped keep the group focused on business value rather than technical goals. I did receive feedback that more up-front detail on the overall process we followed may have been useful in the intro as people weren’t always sure when it was the right time to introduce an idea/concept (none of the attendees were familiar with creating a story map before the session).

The team (individually – silent brainstorming) wrote up stickies (all the same colour – purple) about the ‘things people do’. To help stimulate their thinking, I put up some typical users (we ended up trashing one of them). I also took them through the email example (just the user task level) to help get them to the right level. Once everyone was done scribbling, they did the grouping and naming exercise as demonstrated in the video. We actually struggled with our user tasks being too high level (e.g. manage xyz) rather than too low-level: it did help to try to get the team to start tasks with verbs where they had to break it down a level.

We prioritised the groups and user tasks from left to right and ran through some scenarios. This highlighted a lot of gaps that hadn’t been clear before. At this point the group were getting quite tired and it was nearing lunch time. If I’d had time, I probably would have given everyone a long break at this point. As it was, we only had time for a coffee and tea break. Until now, all the work had been done on a large table in the centre of the room: I now put the skeleton up on the board (not wide enough) for the next part of the exercise. You need a very wide space for story maps!

The next part was not done as comprehensively as we would have liked. We skipped writing stories for some user tasks that we knew wouldn’t be in our first slice and didn’t get into the detail of the second application we’d identified. We also did not write stories for work that we’d already done, which created some confusion later. We still got what we needed out of the exercise, but more time would have been good, and we will need to revisit parts of our skeleton. There’s also a (low) risk that some of the tasks we’ve left out for now are actually risky/important for our first slice.

That marked the end of our first session as we were already thirty minutes over time. Throughout the session, I encouraged the team to write down issues, risks and assumptions on bright pink stickies so that we could ensure we addressed them appropriately and did not forget about them. It also automatically created a parking lot, because anything that was relevant overall but not to where we were in the process could be parked (and eventually they did all find a home, either on the story map or as impediments in our impediment backlog).

Things that I felt worked well:

Being strict about using certain coloured stickies to represent particular things. This also made it easier to reproduce the map in a different location!

The email example was useful for framing what level we were speaking to.

The individual brainstorming and grouping approaches both worked really well. They got people on their feet and everyone engaged once they got the hang of it.

Do try to stick to the recommended 5-7 person limit.

The product owner was happy to see the team focusing on a business goal rather than a tech goal.

Things that didn’t work well:

We didn’t cover all the scope when we created our stories. We may have missed something.

Time. In the end, we needed three-and-a-half hours to complete both sessions (which wasn’t far off my gut feel of four hours).

Related to time, the team got tired. We could have done with more breaks.

The conversation about and agreement on the goal should have happened before the session.

Ideally this exercise should happen before work has started, as having done and partially done stories did confuse matters when creating the map.