Affinity Prioritisation
Recently faced with the challenge of getting 136 epic stories prioritised fast with a group of stakeholders before the team started to estimate, we tried something that was new for me, using an affinity approach to prioritise.
Often that initial prioritisation of a Product Backlog can take a while as you try to assign value to each item or discuss the relative benefits of each story. However we had a team who were ready to go with estimating and we wanted some notion of priority, so that the team could focus their efforts correctly when estimating. Therefor we decided that we didn’t need business value associated with each item, that could come later, instead a prioritised list would be sufficient.
We planned to use affinity estimation to T-Shirt size the Product Backlog, so we thought why not use that kind of idea for this initial pass at prioritisation. We were able to get all 136 stories prioritised within an hour, with 5 stakeholders participating.
Here’s how it went:
Starting out
The Product Owner introduced a story and placed it on a table. The next story was then introduced and he said if he thought it was higher or lower priority, if it was higher priority it was placed on the left, if it was lower priority it was placed on the right. At this point discussion would break out and an opportunity given for others to move the story. Then another story would be introduced and placed in relative priority to what was already laid out. Some stories might bob around for a while, but eventually they settled down.
Evolution
We had time-boxed the activity to 1 hour and started a little late, but by the time we had a dozen or so stories the space on the table started to take on a life of its own, and now we had a baseline the pace picked up. There was now a group of high priority items on the left, some stories that people were talking about medium priority were in the middle and the low priority ones on the right. As the number of cards grew the cards started to be prioritised vertically as well as horizontally, still all relative, but such that the highest priority card was in the top left corner and then priority went down the column and then onto the next.
As we did this the interesting thing was that people started to discuss what it meant for something to be high priority, many of the Epic’s would need some part of them delivering to constitute a minimal viable product, but what made us want to prioritise something high up the list? It was good to let that come out rather than define it up front.
Finally
Starting from the left we then drew lines where we thought there was a step change in priority, and classified them as we had started to discuss as high, medium, low. If we had taken more time we could have been a bit more sophisticated and assigned relative numbers to each story representing the value. We ended the session with all 136 items prioritised, each with a unique priority, ready for the team to estimate.
Prioritisation does not end here, but this was a very fast way of getting an initial prioritisation, and it certainly helped start the conversation about Product Backlog priorities.
Final picture above is of me and the Product Owner, note the Vision, which is visible stuck to the TV above our heads.
3 Upper Management Challenges when adopting Scrum
Some challenges that I have encountered as an Agile Coach working in large organisations adopting Scrum and how you could approach such a scenario.
We want to adopt Scrum, but we are not willing to change anything
There is often a belief that brining in Scrum is going to be just a set of new practices for the development team and they can get benefits without changing anything. I have discovered that it is best to address this one early with the organisations senior team, otherwise they will be wasting their time. So education is important, a workshop with senior stakeholders usually does it, just getting them thinking what it will mean for the organisation to deliver working software in vertical slices rather than building it in layers, what will it mean for the organisation to have dedicated teams. These initial workshops help me and the client understand if they are ready for Scrum.
There can be only one
Different change initiatives sponsored by different members of the executive team, this can be particularly painful if you are working with the organisation to move them towards agility, but you discover some other change initiative designed to get control by introducing more management and more structure. There can be only one change initiative, therefore work to join them up, however if they are in conflict work with upper management to see what is most important for them now, sometimes organisations need to take a step back before they are ready to move forward. Just make sure they have the information to make the right decision for them.
The Agile antibody
Sometimes there will be executives who say they are behind Scrum, but behind the scenes they will be fighting a rear guard action to protect their domain, maybe even trying to kill off Scrum inside the organization. This is not always obvious at first, but it will become so when teams struggle to work with their area of the organisation. We obviously want them onboard, so an approach I would use here is to try help them understand how they could benefit from a new world using Scrum. For example the head of testing may be interested to know how in Scrum testing is central to the development process, that they would have much more scope to influence the quality of the products.
Cool Wall Retrospective
This post is republished from my old blog
At the Munich Scrum Gathering (2009), Harvey Wheaton from Supermassive Games did a presentation entitled “Growing Self Organising Teams”, which was exceptional and I found it very inspiring, the presentation can be found on the Scrum Alliance web-site. In the presentation one slide caught my attention and it was how the team had used a Cool Wall, inspired by Top Gear (popular car show in the UK). I thought that would be an excellent tool for a retrospective and used it at the next opportunity, this is how I used it. Picture not great, but you get the idea…
Using the Cool Wall to Gather Data
The team was asked brainstorm team practices/team customs/patterns/ways of working, each team member then took it in turn to add their practice to the cool wall, and share it with the rest of the team. Sub-zero was for practices where the team felt they were world class, seriously un-cool was reserved for practices that really weren’t working.
I then asked the team to vote for the practice they wanted to work on, I had forgotten my sticky dots so we used marker pens. The team actually picked a practice from Un-Cool as the stuff in seriously un-cool was out of their sphere of influence and the ScrumMaster was dealing with it already.
Using the Cool Wall to Drive out Actions
Once we had selected a practice we had some discussion to understand the root cause. We then moved to generating actions by asking ourselves what we need to do to move this practice one column to the right. Remember you only want a few actions otherwise nothing will get done.
Check-out
To keep with the car theme I then asked the team to say given their project, what mode of transport they most felt like.
Summary
The approach worked well and really helped to create a picture of the work the team does, and uncovered loads of stuff that the ScrumMaster could work on to help the team improve. Also we only spent an hour doing it.
A New Start
A new start, a new blog. This is where I will be posting my thougths on all things Agile. My old blog should still be available.
Exploring Agility 