[Disclaimer #1: Warning: strong Scrum language ahead. If you don’t speak Scrum, you can make it through this blog, but you might need to review the Scrum Guide. For example, I use the Scrum term Product Backlog Item (PBI) which can indicate any requirement in the backlog. The PBI might be in the form of a User Story, but a PBI can be non-functional requirements, technical debt, or anything the Product Owner wants in the backlog.]
- You are <anyone on the Scrum Team.> You are half-way through Sprint Planning and tasking stuff out but realize there is a major dependency that cannot be mitigated. Everything is blocked. Sprint Planning starts over with a new Goal.
- You are the Product Owner (PO). You bring your beautifully written PBIs to Sprint Planning and start planning but you can’t come to a consensus on a Sprint Goal because the Development Team keeps interrupting with things they need to do before they can build what you want.
- You are a member of the Development Team. You are ready to dig in and task stuff out, but the PO hasn’t had time to prepare. The whole team spends the day writing PBIs.
- You are the Scrum Master. You are texting all your buddies asking for a diversion phone call because this train wreck is just too painful to watch.
It needs to be said: Poor Sprint Planning leads to a heavy, bloated, wandering Sprint. A Development Team that just can’t take flight. Work gets blocked for days because the team is waiting on another team or resource to do something important – but they have their own important stuff to do. PBIs blow up, they don’t get finished, everyone is frustrated, and then there is the great rationalization to let stuff slide into the next sprint because it is “almost done.”
If the following scenarios sound familiar, this blog is for you.Safe & Effective
If you or someone you know relate to these scenarios, you may think you should concentrate on making the Sprint Planning meeting better. But that is just a symptom of the real disease. Chances are you need to back up a step to the root cause, poor preparation. Your team could benefit from Refining. (Formally called Grooming. Read why don’t call it that anymore.)
[Disclaimer #2: Refining is not a formal Scrum event, I’ve heard it described as a GASP (Generally Accepted Scrum Practice.) Like user stories, points, and story mapping, it’s a common practice we do to make the Scrum framework more effective, if we need to. If you have a high performing team who meets their goal every sprint and has a fairly stable velocity, this blog is not for you.]
The purpose of Refining is to ready PBIs for Sprint Planning. Refining allows the Development Team the opportunity to challenge the business need, question acceptance criteria, and review and adjust any early sizing. It gives them a period of discovery that stimulates creativity and autonomy. It allows the people doing the work to start thinking about solutions. It provides valuable information to the PO so they can mitigate risk and dependencies early.
Iterative development of the backlog is a key component of the progressive elaboration implied when we use the term “Agile Planning Onion.” Refinement should happen during every phase of Agile planning, continually breaking work down into smaller chunks. But this practice becomes critical between the Product Backlog discussed at priority meetings or release planning events and the Sprint Planning event.
- Refining should take no more than 5-10% of your Sprint. That doesn’t sound like a lot, but in a two week Sprint, that equals eight hours. Ten percent is lot of time when a group of creative, high performing minds focus on problem solving. In my experience, once a refining cadence is started, teams rarely use ten percent – it typically levels out to around one or two 2-hour sessions in a two-week sprint. I suggest putting a recurring refining meeting on the calendar, so the team can plan for it, just like any other Scrum event, and lesson the frequency as you mature the backlog.
- On a true, cross-functional Scrum Team, you might be okay with Refining 2-3 days before the start of your next Sprint. This gives the Product Owner time to get answers to questions that are asked in refinement. If the team typically has a lot of dependencies, there are multiple teams working on one thing, people are new to Scrum, or they really need to see the big picture, it is best to plan 2-3 sprints ahead. More than that, and PBIs can age out, just like old inventory in a store, and may have to be refined all over again.
- For best results, all Scrum Team members need to be involved. If the Product Owner is the only one creating PBIs, they may not know about technical details that will impact the sprint, or how complex something might be to test. This is a great opportunity to mentor junior members and to bring everyone to a shared understanding of the new feature or enhancement. If circumstances dictate that you just can’t pull everyone together, the minimum participation would be involving “the 3 amigos.” I use this phrase to suggest there must be a representative for the business need, one for the execution of the work, and one for the validation. On a software team this typically translates to a PO, a developer, and a tester. It is important that every skill is represented to provide a holistic review of the PBI.
Use & Side Effects
Refine items for different planning horizons at different times. I suggest focus on one planning horizon at a time to reduce context switching. Future work: There is often a need to refine something big and complex at a very high level in order to plan resources and timing. Discussing work at this level (typically epics or features) might include a great deal of ambiguity and assumptions. Refining with just the 3 amigos may be enough to provide the right amount of detail early on, and continuity later when that big, complex thing is ready to be worked on. Immediate Work: Every team should take the time to refine PBIs to be ‘ready’ for an upcoming Sprint Planning. Typically this refining requires more in depth knowledge of the work, so it is best done by the people doing the work. Emergent work: If a team has an item that must come into the sprint, such as a production defect, take the time to stop and refine just as you would to prepare for planning. This helps prevent rushing to an incomplete solution or not understanding the real impact this interruption will have to the forecast and Sprint goal.
Create a Definition of Ready (DoR). Having a Definition of Ready can help a team know they have enough information to get started. DoR is another GASP that provides value during Refining. The Scrum Team determines what elements need to be included in a typical PBI to consider it ‘Ready’ for Sprint Planning. It should help answer the questions: “Do we have enough to get started? Can we confidently estimate this?” (Notice I do not suggest the phrases “do we have enough to finish?” or “do we have enough to accurately estimate?”) On a development team, a DoR might include items such as:
Requirements in the form of a user story
At least one testable condition of acceptance for the happy path and one for the exception or unhappy path
Sized using …fill in the blank with points or hours*If the PBI has a lot of dependencies the team may require those dependencies to be mitigated before they commit to them in a Sprint. Some examples might be:
a) real data needs to be available to build a report
b) a web service needs to be built by another team
c) a legal review of a disclaimer on a web page has to be approved
Start with a simple Definition of Ready and review it at each Retrospective. Just like the Definition of Done, it will change as the team matures.
Capture the decision points, even if they are small. If the Scrum Team is Refining items 2-3 sprints ahead, the details of important assumptions or discussions can be forgotten by the time it is brought into a sprint. This does not mean the whole discussion is captured. Identify key decision points and add them to the PBI so they are not forgotten when it it time to execute.
There is more to consider:
- If you are using an agile tool: how can you use it to indicate what step of elaboration the backlog items are at? Use an attribute or a tag so you can filter by a short list of PBIs that are ready to be refined.
- If you have Business Analysts or User Experience experts: avoid ‘solutioning’ by working too far ahead of the team.
- Don’t make your Definition of Ready so difficult to meet that it is unrealistic, so you can’t sustain it.
There is a lot that can go into a Refining session, but it should be individual for every team. Don’t let the need to refine turn into big upfront design or a waterfall sequence of requirements being passed off to development. We must keep the Scrum principle of “Just In Time” in the forefront.
Perhaps that is why it is not yet a formal Scrum event. Or perhaps adding Refining would just cause bloat in the lightweight framework of Scrum.
Reach Your Goals
I’ve described here some things that work for my teams, to help keep their Sprints be as clean and interrupted and as light of foot and spirit as possible. Let me know if Refining helps your team solve their bloat.
Live your truth; hone your craft; show your thanks