Bill Wake's 2003 article explaining the INVEST acronym is STILL among the best guidance ever written for writing effective #productbacklog items.
Thank you, Bill. 🖖
Original article: https://xp123.com/invest-in-good-stories-and-smart-tasks/
Bill Wake's 2003 article explaining the INVEST acronym is STILL among the best guidance ever written for writing effective #productbacklog items.
Thank you, Bill. 🖖
Original article: https://xp123.com/invest-in-good-stories-and-smart-tasks/
Bill Wake's 2003 article explaining the INVEST acronym is STILL among the best guidance ever written for writing effective #productbacklog items.
Thank you, Bill. 🖖
Original article: https://xp123.com/invest-in-good-stories-and-smart-tasks/
@billseitz @bernie @anil Ok. Background check the three of us help organizations with Scrum, Kanban, DevOps etc.
FWIW I know and love (platonic) Ron. I've read that post, many times. One could argue our 3% Better Approach is an antidote to Ron's point.
I'm open to another another angle. Should I write about #ProductBacklogRefinement for Kanban? How does it differ from Scrum land?
Their item still spent a long time sitting in a queue and it doesn't matter what the queue was.
What other tips would you offer? (Fair warning, I will tell the world).
#EffectiveMeetings I'm slowly looking to every single detail I can find on #ProductBacklogRefinement
A ThreePercentBetter Production In partnership with @bernie and @anil
3/3 Bad Estimate
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.
#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.
Refining the backlog is how you take big ideas and unclear needs and refine them into chunks of work for the scrum team. The activity adds details including a description of the work and sizing. It’s an essential part of delivering usable increments of value each sprint.
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.
Write in candidates are also appreciated.
A ThreePercentBetter production in partnership with @bernie and @anil
#EffectiveMeetings #BuildInPublic #Pivot
Help me understand:
This set of tips summarized from https://www.shortcut.com/blog/how-to-do-backlog-refinement-less-wrong
What other tips would you offer? (Fair warning, I will tell the world).
#EffectiveMeetings I'm slowly looking to every single detail I can find on #ProductBacklogRefinement
For many software development teams, backlog grooming, or, as it’s becoming more commonly known, backlog refinement, is seen as a necessary (and sometimes unnecessary) evil. How can we make backlog refinement productive and enjoyable again?
- Collaboration should involve hearing from all voices, a good ScrumMaster should be facilitating to give everyone an opportunity to share
- Don’t get too far ahead - 3ish Sprints of well understood work is enough. (Some will argue even less is better)
- You don’t need to detail each and every acceptance criteria in Backlog Refinement
What other tips would you offer? (Fair warning, I will tell the world).