Using (Agile) planning poker for risk assessment of IT changes

Introduction to (Agile) planning poker

In Agile software development, work (new features, maintenance tasks, etc) is timed boxed into sprints or iterations of a fixed time period, usually somewhere between 1 - 4 weeks. Before each iteration begins, the product manager, iteration manager and the team meets in an iteration planning meeting. This meeting aims to determine what work will be pulled from the team's backlog (prioritized list of work awaiting delivery) and delivered in the upcoming iteration. 

As part of this iteration planning meeting, the team will either revise or initially score each story card (piece of work) with points. Points are whatever the team decides them to be but usually points are used to gauge how big a story card is to complete. Story cards can be sized using Fibonacci (1,2,4,8) or t shirt sizes (S, M, L, XL). The team usually knows how many points they can deliver in an iteration so assessing each story card, assigning them with their respective points and checking the total points for all of the story cards in an iteration will ensure that the team is not over-committing itself for the iteration.

One method commonly used by teams to size cards is planning poker. Planning poker involves each team member possessing a card for each point of their rating scale, for example if the team uses Fibonacci 1, 2, 4, 8 (4 cards). As each story card is pulled from the backlog, each team member presents a card to show what size they feel the card is. There is usually various opinions about the same card so it is common for a discussion to follow where the team shares their assumptions, risks and perceptions about the story card. Eventually the story card receives a value in points but the most valuable part of this process is the discussion between team members on the work or risk involved in delivering that story card. With planning poker, the team gets to share assumptions, knowledge and experience on their work as a collective. I explain this process in the video below (skip to 13:26):

Planner poker for (ITIL) Change Management

This powerful process could be reused in another important area for IT teams, assessing the risk level of planned changes. Traditionally, an individual team member will create a change request and initially assign a risk level to that change. Depending on your change request risk assessment model, this change request may be reviewed by peers, team leader, manager, another party or no one. Planning poker could be used by teams to peer review change requests and ensure a more accurate review of the changes' risk. As an example, the team may meet once a day to review the upcoming change requests awaiting release into production. Each member has a card for each level of risk (e.g. Low, Minor, Significant, Major) and as each change request is presented, each team member shows their risk level card. From this point, a discussion will follow where team members share their assumptions, knowledge and experience on the change request as a collective.

Not surprisingly, you may have concerns about hosting yet another team meeting. However I argue that smoothly releasing changes into production is integral to delivering value to the customer and therefore worth the investment in time. Further to this, your team will gain experience and knowledge as the collective shares information about the planned changes rolling into production. You could reduce overhead but potentially hosting this meeting in conjunction with your iteration planning (assuming you run such meetings). In other words, as your team is sizing a story card for effort, they could use that the opportunity to jointly assess the risk of releasing that story card into production. Hopefully the discussion could then move into identifying opportunities to reduce the risk of story cards being perceived as Significant or Major changes. 

I hope in this blog post that I've given an example of how to leverage the collaborative power of the planning poker process,  for activities outside of its original purpose. Planning poker is a great way to bring a team together and allow them share their experiences and perceptions for the greater good of the team and the customer.

Popular posts from this blog

Using the Lean Canvas for an IT solution proof of concept

Seamless and scalable IT major incident management

Applying Scaled Agile Framework (SAFe) to IT Service Management and IT Operations