How big is it?

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?

First, there are some principles/facts-of-life that are important to bear in mind:
1. The cone of uncertainty
2. Some practical examples of the developer cone of uncertainty
3. A good analogy of why our estimates always suck, no matter what data we’ve used

In the beginning….

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?

[Retrospective Lessons] Stories and sizes

This photo is the list of actions/changes/learnings one of my teams came up with in their most recent retrospective. This did not come from someone who went on training or read an article. It also didn’t come from a new Agile coach or Scrum Master. It came from them missing their sprint commitment and goal. This team only managed (on paper) to complete 8 out of 18 points; but they all knew they had delivered and learned a lot more than that measure reflected.  Here are some things that they decided to do going forward:

1. If the team cannot reach consensus about the size of a story, then split it into two stories and size the smaller stories

One of the main reasons the team had such a poor burn-down is that they took in one quite large story which did not quite meet the INVEST requirements. For one, it was a ‘common component’ that was to be used in most of the later stories (so not independent). It also was not small enough – and turned out to be even bigger than the team had thought. During sizing, there had been some debate about its size and eventually reluctant consensus was to make it the smaller size. Turns out the less optimistic team members were right. This was one of the stories that was not done at the end of the sprint.

2. Keep Planning II – and use it to verify the sprint commitment

This is a team that often decides to skip Planning II (I don’t like it, but ultimately it is the team’s decision and so far we’ve muddled along without it). For this sprint, they decided that they did need a session to unpack the stories and how they would be implemented. Everyone agreed that without Planning II we would have been even worse off. They also realised that at the end of Planning II, there were already some red flags that the big story was bigger than everyone had thought and they could have flagged,  at that point, that the commitment for the sprint was optimistic. The team agreed that, in future, if going into the detail during Planning II revealed some mistaken assumptions, then the team would review the sprint commitment with the Product Owner before kicking off the sprint.

3. Feel free to review story-splits in-sprint

Early in the sprint, the team were already aware that the big story was very big and probably could be split into smaller components. Their assumption was that this wasn’t possible once the sprint had started. For me, re-visiting a story split mid-sprint or once you start the work is not a bad thing: sometimes you don’t know everything up-front. It also, in the case where a story is bigger than expected, gives the Product Owner some more wiggle room (negotiation part of INVEST) to drop/keep parts of the story to successfully meet the sprint goal. Of course, where we have got things really wrong, then sometimes the sprint goal cannot be rescued and the sprint would be cancelled.

4. Raise issues as they happen

Pretty much summarises most of the above points. One of the agile principles is responding to change over following a plan, so when change happens make it visible and decide how to adjust the plan at that point. There’s no point in battling on as planned when you know that the planned path is doomed to fail.

Some references:

• INVEST
• More INVEST
• Some options for when you’re struggling to create an INVEST story
• INVEST stories and SMART tasks
• Always useful story-splitting cheat sheet
• And something on failure

Ever changing, never ending

I recently read the following article (which I am assuming was written within a Scrum context). Basically, it builds a case for a Product Owner to add more scope to an agreed sprint. It warns that this does frustrate the team and potentially impacts quality, however says it can still be done with the correct amount of justification. The basic agile principle that it bases this on is “Responding to Change over Following a Plan”.

This doesn’t sit well with me at all.

Messing with agreed stories once a sprint has started should be the exception and not the rule. It is very disruptive and de-motivating. Scrum uses time-boxes to limit work in progress and ensure team flow and sustainability (all lean concepts). Continuously changing sprint scope means it’s harder to complete stories to deliver working software. Scrum says that if you need to change the scope of the sprint, you should cancel the sprint. That means stop working, review the stories that are done, have a retro (after all, we need to understand how to improve so that we can avoid cancelling a sprint again), clear the task board, and plan and start a new sprint. It’s a significant event so the process around it should recognise that significance.

My preferred tool for managing change vs plan in sprint is a sprint goal. Agreeing an overarching sprint goal empowers the team to tweak sprint content (with Product Owner input) where it makes sense in terms of the overall goal for the sprint. If new stories arrive that are not aligned to the goal then either the Product Owner must wait for a new sprint to start or acknowledge that the sprint goal is no longer valid (and cancel the sprint). If your goals/requirements change often, consider shortening your sprint lengths. If they change so often that it is impossible to plan a week in advance, then perhaps a more Kanban-like approach will be better suited.

For me, changing stories mid-Sprint when you’re running Scrum points to a deeper issue, and merely substituting/adding stories addresses a symptom rather than dealing with the cause. There would be a number of ways to address that cause (sometimes it’s merely a case of educating the business or learning to say ‘not yet’). The important thing is to ensure everyone is aware that this is a big deal and help the team find the best way to deal with it in a way that ensures all agile principles are satisfied.

Picking our slice

(Part 2 of 2)

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:

1. A better understanding of the short-term and long-term goals of the project.
2. A ‘first slice’ to test our architecture, resolve some technical challenges, and deliver some business value in production.
3. A first pass idea of the size of the full scope of work.
4. 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!

Links

• Part 1
• More detail on bucket estimation
• 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).
• Affinity Estimation How-to 

Creating our first story map

(This is part 1)

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

1. We’ve already started working
2. It’s about replacing something that already exists
3. 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:

1. 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).
2. 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.
3. 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!
4. 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.

Links

• Watch the video! But here are some more facilitation tips.
• Simple overview
• Some more detail (plus more on vertical slices)

Video: User Story Mapping in Practice

A must-watch for anyone interested to learn more about story-mapping and/or slicing and visualising projects/products better.

Story-Mapping Video