#DefinitionOfReady
Under some circumstances a Definition of Ready helps a Scrum (or Kanban Team) ensure their Product Backlog Items are well thought out. This means nothing is consider for Sprint work that would get probably get stuck.
I've already pointed out that ready encourages mini-waterfall/gate system.
Another reason to dislike Ready, it encourages a local optimization. It makes the Scrum Team look good, by improving their cycle time, without necessarily improving things for the client. Example a Definition of Ready holds up a feature for 4+ weeks will requirements are being gathered. Now the Scrum Team looks good when they work on the item their cycle time will be low. However the customer isn't any happier.
Pivot in Public. Nearly a month of writing about #ProductBacklogRefinement I'm seeing little engagement. As a student of #LeanStartup I want to learn from my audience.
I love the title Less Wrong Backlog Refinement. This article pleasantly surprised me. This is a tool vendor site (it’s goal is to be a better than JIRA Scrum/Kanban tool), most tools vendors do not understand Scrum.
They open with Anti-Patterns:
Meeting is used to assign work
Team Member My opinion doesn’t matter, often because the PO is telling, not listening
Everyone has a different definition of ready. (Hint I warned that Ready has some risks)
Product Backlog is being refined 6+ Sprints out - too much detail too far ahead team members feel their time is being wasted.
The Cure (cue 80’s music)
PO preps before refinement - they deeply understand what they want worked on, they know who needs to be there and as others have suggested they might even tell people in advance what will be worked on
An article I read tells a story of team struggling during their Sprint suffering from mini waterfalls because their Product Backlog Items were ill defined. (A sad oft heard tale). So they set about curing the problem. Just be aware that the cure, Definition of Ready, can become part of the problem at a later date. In this case the Definition of Ready: Clear, Small and Testable; feels like a restatement of INVEST (which the author also mentions).
I’ve seen Definition of Ready go off the rails when it becomes a long list and returns us to waterfall style gate system: Product Backlog -> Definition of Ready -> Sprint Backlog -> In Progress -> Definition of Done. The two “Definitions” one formally part of Scrum, one informal become the traditional phase gates.
If your Definition of Ready is short and to the point, it maybe helping clarify the work.
Backlog Refinement can prevent Zombie Scrum - I love the phrase Zombie Scrum. It conjures to mind teams using the practices of Scrum and getting limited benefit. They ran a workshop with their subscribers to find what was helping them with #ProductBacklogRefinement
The tips:
Vote on which item(s) in the PB are least clear
Invite Stakeholders to the refinement session - in particular stakeholders who have PBIs that are near the top of the Product Backlog
Pick a the two largest items destined for the next Sprint and split them into at least 6 items. Whoa for many that will be hard work.
Bring the bottom ten PBIs to the next Sprint Review meeting and offer to drop them. This is a hell of incentive to get stakeholders to attend Sprint Review.
Trying Running after DS, when the team is already spent time away from task work, this works well in teams that resent refinement feeling it interrupts the flow of work
Pair Refinement, pairing not just good for programming, now pairing makes refinement better. Seriously sometimes working in a smaller group for a short period makes better than working in a large group
Prep work, share items to be refined prior to the meeting
If there was any single blog in this series (aside from my own :-) that I might suggest you follow it is The Liberators. Too bad Medium makes it impossible to get an RSS feed.
What other tips would you offer? (Fair warning, if I agree I will tell the world).
For me the deeper thought is if you hit violate the limits often or feel the urge to re-estimate in Sprint Planning, it’s probably a sign. Consider a deeper discussion in a Retrospective. (consider NoEstimates).
Not linking to the original post b/c I’m not trying to pick a fight with the author. I might differ with some suggestions not the person.
Refinement was taking so long even after two time slots in a Sprint, the team still wasn’t ready for the next Sprint. The author’s change was to limit refinement on any item to four mins.
1st min - PO gives a quick recap
2nd min - Team questions
3rd min - Planning Poker round to find outliers, who explain thinking
4th min - Planning Poker again majority rules.
...
Halt. Cue the irony. Planning poker was invented to solve the very problem the author was having. Fast forward 20 yrs and the problem pops back up. I think it’s a hydra.
Most planning poker rounds, whether Story Point, T-Shirt sizing or gummy bears should resolve themselves after 3 rounds. The majority rules adopted by the author increases the likelihood that outliers and/or quieter team members will feel silenced.
Context - use when you have a larger volume of PBIs to rapidly sort through: 1 1/2 -> 4 mths worth. This is focused on speed over precision. (Hint no estimation technique is precise)
We’re using to get a rough sense of the size of the Product Backlog and to see which items need deeper discussions right away.
On a floor/wall/mural/miro create buckets labelled with the familiar 1,2,3,5,8,13,20 sequence or XS,S,M,L,XL or what ever sequence works for you. Add ‘?’ category as well.
Round 1: All team members grab a handful stories and start placing them at the estimate that makes the most sense. Use a ‘?’ for items that are ill understood. At the end of round 1, all the stories/PBIs should be place. This round is silent.
Round 2: Team members examine the where all the items are placed, if you think an item is the wrong location, move it. Make note it was moved and what the original estimate was.
At the end of round 2 items that haven’t moved have a good enough estimate. Items that only moved one step, likely also have a good enough estimate. Hand these to the PO.
Barry often continues for a 3rd round. On the other hand if the number of items that don’t have estimates is just handful I might run a traditional game of planning poker.
What other tips would you offer? (Fair warning, if I agree I will tell the world).