Facilitating a Backlog Creation Workshop

As part of our Sprint 0 tasks my team decided to hold a product backlog creation workshop. This is something often mentioned in agile and Scrum guides, but not really defined anywhere. I’ve used most of the the tools I pulled together separately before, but I’d never used all these tools set up in a workshop this way.

I started by setting the goals of the workshop and running through the agenda which I had on cards up on the wall with timings on (where I knew them).

These were:

png;base641d4466bd5a607c2epng;base64f4f45736df8052fcpng;base64ee86464fb4c8c429png;base646780f09e4e3f5150png;base64c2526e610c7ea34epng;base647c799af173059b42

Goals of this Release

The first exercise was to review the goals of our release. These had already been identified in producing our “Inception Deck” the previous week. This made sure we were all focusing on the same scope which is particularly important for our team as there are several planned phases and releases to our project (these may change as we go, but are in the product road map).

Persona creation

We then generated our personas. I used the set up and template from Roman Pichler. The article is far more thorough at explaining itself but the top line is: This is focused on agile, just “good enough”, personas suitable for focusing agile teams’ development.

Starting with personas puts the user at the center of story creation as well as helping manage stories on an ongoing basis.

We first identified the personas by brainstorming roles then applying the template to each role. I did one with the team as an example, then the group split into pairs. Each pair applied the template to one persona and then shared it with the team making a few quick edits. In total we now have 6 personas which are displayed on the wall in our team area. Splitting into pairs was a good way to speed up this and also check that everyone is on the same page; a side benefit was that this seemed to create a shared ownership more naturally.

The team then identified whether each persona is a user or a customer (customers being the ones who pay for the development) this helped identify another persona. We picked a Primary persona who was our main focus when delivering value, in the case of Rialto this is our Author, Charlie. This can be used as a tool for deciding between the priority of conflicting roles’ requirements.

The persona creation took much longer than I’d expected, I had allowed 15 minutes, which in hindsight was never going to be enough, overall this took about 45 minutes. I could have probably cut this down to 30 minutes, but there was a lot of valuable discussion going on that the team was finding useful. With a team who are established, working on an existing product, 30 minutes would work I think.

Values or Benefits

The next task was listing and identifying any further values and benefits that those users will get from our systems, or that we want to offer. Again this was linked to the inception deck.

We then had a break for lunch.

Story Creation

In the afternoon we tackled story creation and estimation.

How I had planned it:

  • Product owner takes us through her epics
  • Team identifies any missing epics
  • Break up each epic into any clear component stories
  • Relate those stories to the personas and benefits

What actually happened:

  • Product owner took us through her epics
  • Everyone struggled to see how to break the first one down and got very distracted
  • People started looking at me a lot, I felt that they were expecting me to tell them what the next story was
  • I explained that I wasn’t there to identify the stories that they would need to do that
  • We got out the high level swimlane diagram that our architect had already completed before the rest of the team was selected.
  • We then identified a completely new set of stories based on what each of our personas would want at each stage and what benefit they wanted from that etc.

Once we’d run through the complete user journey we then validated these against our original epics to see if we’d missed anything, this drove out a few extra stories

This all took about 2 and a half hours, I’d provided fruit and biscuits to keep us going. Without a information flow diagram just thinking through user journeys would have covered this really. I think next time I’d try user story mapping here to provide more structure.

Estimation

After another quick break we looked at sizing the stories. I used affinity estimation, partially as this came from my Scrum trainer Lowell Lindstrom, and partially as I’ve used it to good effect before.

At a high level: you order the stories, in silence, from small to large; you then have a quick chance to talk and edit that ordering; you then bucket estimate based on the ordering; followed by some discussion based on the estimates led by the PO.

Everyone found the ordering really useful, one developer said it helped to see things in perspective. However, they didn’t seem able to bucket the tasks based on their ordering. Rather than seeing it as breaking the line up into sizes, so say items number 4 to number 10 are 5s, they needed to discuss every ticket to size it. This then took up the rest of the day rather than being a relatively quick exercise. I think this would be much faster with a more established team. Perhaps the new team maybe didn’t trust their estimates without double checking them. At this stage I did also start to see people getting a bit confused over what stories meant, and second guessing themselves.

Towards the end of the bucket estimation part the developers were really motivated and wanted to finish even though it was slow going. This lasted until 6pm when we had finished.

We did manage to finish with an estimated backlog and personas, but didn’t have time to discuss any cards. I’d really have liked to have time to let the team watch our Product Owner prioritize the cards too. We’ll have to do that in grooming as I think there is massive value in it.

Some of the team, although they found the persona exercise really useful, found referring to the personas in the stories a bit less intuitive than having role names like as a reader or as an author. I think this is something I’ll get more feedback on as we go as I can see why that might be confusing for people outside the team too.

If I was to run this again I’d start earlier in the morning. We started at 11 and finished at 6, but I definitely think that people were very tired at 3 points in the day, just before and about an hour after lunch, and about half an hour before we finished. I’d like to try and take this into account next time and get people moving around a bit more to keep them thinking. Starting as close to 9 as possible and finishing before the day was out would have worked better.

In conclusion running a workshop like this is a great way to produce a user focused backlog that a team are invested in and have a good idea of where they would start to implement it. You could bring in one or two of further business stakeholders and still keep it focused, I think, as long as they were familiar with agile development. We had 8 people in the room, 10 is probably a top end. The agile inception deck for the same scope was a solid foundation that should have been produced by the same people, preferably close to this session.

Originally published on my internal blog at Macmillan.com

Advertisements

One thought on “Facilitating a Backlog Creation Workshop

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s