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

Employing value streams in Enterprise Service Management

Image
Introduction Enterprise Service Management (ESM) is the technical extension of pre-existing Information Technology Service Management (ITSM) to other areas of an enterprise (e.g. Corporate or Shared Services). Successful ESM balances efficiencies gained from employing standardised process management, tooling and reporting with the nuances of organisational capabilities such as Finance, HR, Facilities and so forth. ESM leverages the industry proven service management concepts from ITSM that have been available for more than 20 years. Further to this, ESM operations implement similar concepts as ITSM including a service desk for 1st level support, end to end process management, request/issue management software, self-service knowledge bases and more recently chatbots and AI. Value streams are born from Lean manufacturing and comprise of a series of steps an organisation undertakes to create and deliver value to customers, typically in the forms of products and services. In the IT co
Read more

Using the Lean Canvas for an IT solution proof of concept

Image
I was assisting a client with sourcing some new IT solutions. For one particular IT need, the client had shortlisted a potential solution with a trusted vendor but they needed to explore the potential solution further to understand its capabilities in more detail. They were unclear as to whether they should directly source with this vendor or go to the wider market (with a Request for Proposal (RFP)) to address this particular need. Further to this, it was unclear how long this project would run for so it was important to understand the time and effort that may be involved without consuming too many resources.  The client was seeking to employ a specific approach for this potential solution, where a “fail fast” lean Proof of Concept (PoC) would be conducted to rapidly test whether the potential solution was fit for purpose without spending unnecessary time and effort required to conduct a RFP. To start, we confirmed the following principles to guide the PoC: Do not develop
Read more

Improving your IT service delivery and operations with ChatOps

Image
Introduction IT organisations are under pressure to reduce idea-to-product cycle times while improving the service availability of the diverse range of systems and technologies under their charge. In response, IT leaders are seeking to leverage technologies and delivery models such as cloud, infrastructure as code, Continuous Delivery (CD), Big Data and IT Process Automation.  This intersection of contemporary concepts is deriving new IT delivery patterns which are impacting on traditional IT service management (ITSM). From my recent experiences working with Australian enterprise-sized IT organisations, it is my view that ITSM & Operations teams are not keeping pace with their peers in application development to meet current business demands. ITSM and Operations cannot remain effective and efficient if the teams continue to work in disjointed practices that are underpinned by manually executed processes and activities. To remedy this situation, ITSM & Operations teams need
Read more