Agile issue and risk management sunny1
2 likes1,239 views
- A risk is an uncertain event that could impact plans if realized, while an issue is a risk that has already occurred. Risk management aims to prevent risks or minimize their impact. - Agile risk identification occurs through requirements workshops, planning poker, daily scrums, sprint reviews, and retrospectives. Risks are assessed based on probability and impact. - Common risk responses are mitigation, avoidance, containment, and evasion. Risks are regularly reviewed to ensure appropriate response and optimize the process. - Agile addresses issues daily in scrums and tracks reoccurring issues using snakes or calendars to improve over time.
Agile issue and risk management sunny1
- 2. What is a Risk? A Risk is an uncertain event that could impact your chosen path should it be realised. Risks are events that are not currently affecting you – they haven’t happened yet. Once a risk is realised, it has the potential to become an Issue.
- 3. Aim of Risk Management 1) Prevent the realisation of a risk or 2) to minimise/manage/neutralise the impact of this risk once it has been realised. If you succeed in point 2 then the net impact of realizing the risk may be totally acceptable i.e. no issue at all.
- 4. Risk Management for Projects Agile Risk Identification Agile Risk Assessment Agile Risk Response Agile Risk Review
- 5. Agile Risk Management – Identifying Risks • In Agile environments, the team shares responsibility for identifying risks that might affect a sprint, project or programme of development. • The Scrum meetings provide a strong forum for identifying risks on a daily basis.
- 6. Identifying Risks(Cont…) Requirements Workshop: – The team and the Product Manager discuss new ideas and a rough idea of the effort required to deliver them. – This conversation allows the Product Manager to re-consider and/or adjust requirements in a way that maximises value and minimises risk/uncertainty. Planning Poker: – Here the team estimates the relative size of each User Story. – This is yet another opportunity for a Product Manager and a team to reduce risk by rejecting User Stories over a certain size – they’re either broken down into smaller stories. Scrum of Scrum: – In this session, we review project-level progress, risks and issues. The session is attended by the Scrum Master(s), Product Manager and Product Owner(s).
- 7. Identifying Risks(Cont…) Sprint Planning: – Sprint Planning is yet another opportunity for the team to identify, assess and respond to Risk. – They only accept work they feel confident about delivering. The Daily Scrum: – Once the sprint has commenced, the Daily Scrum becomes the main forum for raising Risks and Issues. – We ask the question “Is anything blocking you or likely to block you from progressing as planned?”. – We add highlighted risks to the Risk Board and catch up with the individual after the Daily Scrum to gather more details
- 8. Identifying Risks(Cont…) Sprint Review: – This session also provides an opportunity to highlight successful mitigation activities – it’s good to keep your stakeholders informed of what’s going on. Sprint Retrospective: – Retrospective discussions will focus primarily on the idea of continual improvement and Risks can be unveiled at this session. – The key questions answered at a retrospective are: • 1. What went well last sprint? This could be the successful handling of a risk. • 2. What didn’t go so well last sprint? This could be the realization of a risk or the re-occurrence of an issue. • 3. What will we do differently next sprint? This could include risk mitigation activities.
- 9. Agile Risk Management – Assessing Risks We use two measures to describe a risk: The probability/likelihood of it being realized The impact it will have if it is realized
- 10. Assessing Risks(Cont….) We assess Risks based on their severity. Let’s take 1 being low impact/probability and 5 being high impact/probability • A User Story is severely underestimated in the first sprint, compromising the team’s ability to deliver their commitments (1,5) • A User Story is severely underestimated in sprint 10, compromising the team’s ability to deliver their commitments (5,1)
- 11. Agile Risk Management – Risk Response There are four different categories of Risk Responses 1) Mitigate 2) Avoid 3) Contain 4) Evade
- 12. Risk Response(Cont….) Mitigate: Agile teams employ risk mitigation techniques via their use of ‘Velocity’ – They Stretch Tasks as a way to manage expectations about delivery capacity – The team commits to less but has a number of additional User Stories waiting in the wings for them to consume in the event the risk is not realised. Avoid: This describes a scenario where a project or a part of a project is cancelled in order to remove the threat of realisation. – As described above, the Product Manager will often remove a User Story or amend a requirement in order to reduce or remove an element of risk.
- 13. Risk Response(Cont….) Contain: To contain a risk describes a situation whereby you agree to deal with it and when it occurs. – These risks tend to be low(er) impact and/or less likely to occur thus. – On the other hand, it may be decided that the impact associated with mitigation or – avoidance would have a greater negative impact than the realisation itself. In other words you are prepared to take the risk. Evade: To evade a risk means to take no action at all. – The risks which warrant this type of response are likely to be low impact risks, whose realisation would have little to no effect on project or company objectives.
- 14. Agile Risk Management – Risk Review Risk Review is the final stage in the Agile Risk Management process.
- 15. Risk Review(Cont….) The ‘Review’ stage in the Risk Management life cycle is three-fold: – Reviewing active risks to ensure that responses are delivered in a timely/efficient manner – Reviewing the risk management process to ensure that it is optimised – Reviewing the impact of risks and risk realisation on project and company objectives
- 17. Agile Issue Management • Scrum is great at handling immediate issues they’re more commonly referred to as ‘Impediments’. • Team raises issues daily via the Daily Scrum. • Some teams like to keep track of all of these impediments by using an Issues Snake or an Issues Calendar.
- 18. How this works ? • Every time an issue is raised at the Daily Scrum, you write it on a post-it and place it somewhere visible. • If the same issue is raised more than once, you add another post-it-note to the board. • This helps to keep track of blockages and disruptions and can be used to drive conversation at the end-of-sprint Retrospective or at the end-of-sprint Review. • This approach also helps you to quickly identify re-occuring issues/blockages.
- 19. Issues Calendars Issues Calendars are particularly useful as you can compare them to the team burndown to better understand velocity variances e.g. ‘the team burndown suffered on that day as they were dealing with a particularly hefty impediment.’
- 20. Issues Snake This is another way of maintaining the daily issues
- 21. Agile issue management Vs. Traditional issue management • Agile Issue Management is built into the delivery process- e.g. Daily Scrum • The Team works together to raise and clear issues • Documentation is kept to a minimum – all energy is put into clearing the issue • The team regularly reviews their issue management approach in hopes to improve their handling techniques