Enterprise agile teams often face multiple dimension to the cone of uncertainty such as risk and dependencies. One of Constant themes across scrum ceremonies is to reduce this cone of uncertainty through iterative process. In this article we will try to figure out how Sprint Refinement helps agile teams in this activity.
The Story So Far
You have successfully setup your Scrum team with an initial backlog. The initial Backlog has been created from a Product Roadmap which has been created by the Lean Product Management team to ensure maximum revenue from the product.
The Sprint planning is done for the first Sprint, and the team is Sprinting with a regular velocity. However, you are now faced with a problem. The PBIs for current Sprint have been broken down into granular level to reduce the cone of uncertainty. In a 3 week Sprint, team has already Sprinted for 1.5 weeks. Its time to think about the PBIs which are in Product Backlog. A large number of them might be in EPIC or THEME format and the uncertainty about them would be large. The question uppermost in the Product Owner's (PO) mind is - Will you be able to get the PBIs READY for Sprint planning in another 1.5 weeks?
Solution Definition - Sprint Refinement
The general mechanism followed is twofold -
Prioritisation - Initially the PO will prioritise work based on discussions she has with stakeholders in business world. She will also discuss the PBIs with any SME (Subject Matter Expert) for prioritisation.
Alignment - She will then take these PBIs and ensure through a formal or set of informal meetings with team members and Scrum Master that the items are better understood and can be technically broken down into granular details to get them READY for next Sprint.
Simple as the above activities sound, let us now get down to the brass tacks (or the activities in detail).
Prioritisation - How will the PO get the prioritisation or re-prioritization right? Prioritisation is based on two sources ( as detailed out in Agile Estimating and Planning by Mike Cohn)-
Based on revenue - which of the remaining PBIs create a new source of revenue? It may happen that a PBI might be stopping a loss making activity, in which case it is a channel of revenue in an indirect manner. More importantly, it generally happens that an EPIC can be broken in separate revenue generating PBIs or revenue generating and non-generating PBIs. The discussion with the business sponsor will reveal which revenue streams are deemed more important than others and hence, to be prioritised.
Based on desirability - in case direct revenue model is not available, which of the PBIs deal with must-have features, as per Kano model, of your product? Again, we will find EPICs which can be broken into PBIs some of which are must have while others are exciters? The business discussions will reveal which features are more important to prove the marketability and profitability of the product and hence, proportionately, the priority of the PBIs.
Alignment - Sprint refinement is not an official ceremony and this fact goes a long way in helping you as PO (or Scrum Master) to get maximize the output. A lot of individuals are sometimes reluctant to openly discuss about their reservations in official meetings. Unofficial discussions help such individuals to open up about issues they might foresee. The PO takes the information from prioritization list and discusses with team in either small sessions or larger meetings. However, she will need to ensure at least one meeting with attendance of all team members in order to finalize on refinement details. The following questions need to be answered during the refinement finalization:
Are the PBIs, being targeted to achieve the prioritization goals, granular enough to meet the goal?
If not do they need to be sliced to create separate User Stories? The EPIC will then be sliced into separate PBIs.
Will such PBIs meet INVEST standards for user stories? If not what other changes are needed?
Do team members need more information to do planning for such stories? Are sessions like brown bag meetings needed for background information?
Do team members need external parties to be involved such as legal teams etc for the clarifications about user stories?
The answer to above questions and actions based on them, will enable the team to ensure PBIs are READY by the time Sprint planning comes up. This not only ensures that team maximizes value of increments but also that it maintains a constant velocity.
Are All Input Sources Covered?
As part of Enterprise Agile teams, do you feel that above template covers all inputs for refinement? If you are saying Yes - Please think again! There are other sources which have not been discussed above and which have major ramifications in the life of Agile teams. I will discuss here the template that I use to help scrum teams handle these sources within their Sprint refinement activities:
Risk - Risk management is an integral part of any project, regardless of whether you follow traditional Waterfall model or Agile models. I handle Agile Risk Management through a four stage process:
Identification - Risks are identified during Sprint Planning, Sprint Review and Sprint Refinement. Out of these Sprint Refinement is one of the most important stages as the team has already consumed some stories and hence, can predict risk for future PBIs based on their current knowledge.
Accounting - Risks identified above are accounted in terms of their probability of occurrence and impact on the productivity. In a scale of 0-4, teams are asked to assign both probability and impact in an ascending order. The result of probability * impact then signifies the priority of the risk. The prioritized Risks are then categorized as per the ROAM categories. This accounting practice is handled during Sprint planning and can be modified during Sprint refinement based on our understanding of the issues through Sprinting.
Respond - Those items which are marked as'Mitigate' or 'Owned' are updated during Sprint refinement. Those items 'Owned' by members are discussed with details provided by Owners. Mitigation and resolution of risks occur during the Sprint.
Review - Risk items are reviewed by all stakeholders during Sprint Retrospective with respect to priority and status. Any update of priority is handled during Sprint planning by the team
Estimation technique - There are multiple estimation techniques which can be used for PBI estimation. 3 of the most useful techniques that I have used are - Estimation through experience, analogy or team game. You can read the details in Agile Estimating and Planning by Mike Cohn. Let us say that you have used team game to arrive at an estimation. 1 week into the Sprint, you have found an SME who can give a more precise estimation. Should the PBIs for next Sprint be re-estimated taking the SME's view as well? If you decide to do so, Sprint refinement is the ideal placeholder for such an activity. Correct estimates would mean correct velocity forecasting, hence, all Agile teams should try to modulate their estimations during iterations.
Dependencies - One of the sources which has major impact on any enterprise project are the dependencies. Dependencies can be of multiple flavor such as External/Internal, Software/Hardware, etc. Any large enterprise will have multiple suppliers, vendors and external stakeholders which might impact deliverable of scrum teams. I have written an entire article on how to manage suppliers in an agile world. You can read it here. In this environment, the team needs to be sure that the dependency it needs to start activity on prioritised PBIs will be available by the start of next Sprint planning. The best place to identify such dependencies and request for their inclusion in dependency matrix, is Sprint refinement. In case Scaled Agile principles are being used, Sprint refinement is the place to identify dependencies which need to be sorted out during PI Planning. The following questions need to be answered -
- Are all dependencies identified for the PBIs being planned for next Sprint?
- Which of such dependencies need support from external agencies?
- Have these tasks informed to those agencies? If not, is ownership identified for such communication?
- What is the timeline for such dependencies?
- If dependencies involve other scrum teams, can offline alignment be done or a Scrum of Scrum meeting be arranged to discuss these?
Please note that above scenarios are generally found in medium to large enterprises. Simple Agile projects may not face such complex scenarios and hence, need not have such placeholders.
Conclusion
Sprint Refinement is a collaborative activity involving multiple stakeholders. We can clearly identify sources from which we can collect data during Sprint refinement, to ensure that our PBIs move from extreme uncertainty to predictable items in the ‘cone of uncertainty’. In broad terms, as the team comes to terms with its future course of action and delves deeper into its future activities, probability of failure reduces. Stories can be sliced either Vertically as per flow or Horizontally as per feature based on updates available during Sprint refinement. We can therefore conclude, that to achieve the goal of maximising value stream, Agile teams will find in Sprint refinement a most potent tool.
About Me : A passionate Agile leader having 16+ years of experience in software industry, I have handled Agile projects of various complexities. Having successfully handled Agile transition for multiple organizations, I write about my experiences, challenges and some solutions.