Thread by @lissijean

So here’s an observation and question for the #scrum community.

One of the biggest issues I’ve seen with teams new to scrum is backlog refinement. Most people do it wrong and it has huge implications on #prodmgmt. /1

I have seen hundreds of teams treat backlog refinement as a two hour meeting where they rewrite user stories and estimate them.

While both of those are good things to do, they usually only do these two activities, instead of creating shared understanding about the work. /2

Teams don’t spend this time story mapping, discussing in detail, or contextualizing the end state of the product together.

Actually teams new to scrum usually don’t do any of those things. /3

POs often ask me “when are we supposed to collaborate with the team and sketch and break down the work, etc. We never have time”

To which I reply backlog refinement can be a time to do some of these things. They are usually shocked at this answer. /4

I honestly was too until @RonJeffries told me that it could be used for it, as I’ve never ever seen a team use this time to develop context together, even though the Scrum guide says it. /5

There’s huge implications to teams never stopping to develop a shared context and end state vision of the Sprint or feature.

Usually there’s no scoping the work down and there is tons of confusing around what we’re building and why. /6

So my question to the community:

Where did this bad practice come from when most scrum literature I read does say to take 10% of the Sprint to develop the shared context and break down work? /end #agile