It was the annual event of ‘Meek Week’ last week. This means it was my birthday and made all my friends treat me like a princess for the whole week. I am pleased to confirm they did not let me down! We had lots of meals, giggles, mini golf and of course cocktails! A few photos of my besties 
Every now and again I get the opportunity to be a ScrumMaster, rather than just the coach. I actually quite enjoy this because it means that I can try out new things with my teams and there is also something exciting about being part of a delivery. Don’t get me wrong, I love being a coach and trainer but sometimes I believe we have to go back to the battle grounds, just to remember how hard change can be in organisations.
In one of the teams I was looking after I was fortunate to be able to kick off a new project with them. As we are client facing we are often asked to look at ideas based on little information and give them a rough size of effort. I had been talking about using risk factors for a while in conjunction with story points, and so this was my opportunity to really put it into practice. We were asked to create a high level estimate and so we didn’t have anything more than potential epics at the time.
There is much misconception about what story points represent and many people believe they are based upon complexity, when really they are based upon effort. I wanted to make this really clear to my team and so I introduced 2 numbers during story preparation to help signal when more complexity is involved, and to help us manage these and the risks and impediments that might follow.
I created a simple scale, though you can use whatever words work for your team.
1 – Low risk (there is never none!)
2 – Moderate
3 – Increasing
4 – High
5 – Significant
I then asked the team to discuss each story, vote using story points and then vote on the risk factor. Due to the fact that we were very early on and some of the stories were just high level ideas I made sure that any assumptions were captured.
I was then able to ask them on any items with a risk factor greater than 2 to articulate the risk, so we could then look to mitigate it. A example of a couple of entries.
After completing the exercise the Product Owner and I were instantly able to look down the list and understand what items were large due to lots of unknowns (so high risk factor), and them systematically work through them until the team was happy to split and reduce the complexity. We could also tell which items were just big, but understood in how were are going to deliver it.
I also had a list of assumptions that we could have to aid conversations with clients and what’s as equally important is I had a list of risks and technical decisions that we needed to have sight of and mitigate.
On presentation of these estimates to the architecture group and the CTO the team was told ‘These are the best I have seen to date’ We were even taken to the pub to celebrate.
So a very simple technique that has made discussion, understanding, risk and potential decisions far more visible than the previous way they were doing things.
As a ScrumMaster it is important to me that I understand all the areas that could become a potential impediment to me. ScrumMasters often to forget to manage the risk and so then just fire fight impediments.
Final Thoughts
However your organisation decides to estimate and understand risk (trust me they are all different). It is important that you have the conversations to stimulate actions and visibility. Whilst Agile is about flexibility, it doesn’t mean we don’t have to exercise some level of control.
Ask yourself and your team today ‘Do you know what the risks are of what you are delivering?’
Leave a Reply