Part IV : Survival of the unfittest – how 'Grooming' actually hurts your project

I agree that any individual that is an impediment to the Scrum Team needs to be addressed. If the Product Owner is absent, will not maintain the Product Backlog, does not understand the market, etc, there is a problem. If the Development Team does not deliver a usable increment, is stagnant in process improvement, works in sub teams, etc, there is a problem. If the Scrum Master does not understand the framework, attempts to control the team, does not affect change, etc, there is a problem The self-organizing team needs to address these issues. Of course if the organization does not support agile software development values or the Scrum framework . . .

Product Backlog refinement is not a Scrum event. With things flowing well, there may be no need for any formal refinement in the Scrum Team's operations. Perhaps through a collaborative Sprint Review event with customers, the Product Owner properly maintaining the Product Backlog, a forward looking Development Team, and open communication when some clarification is needed . . . then all can be well.

That requires a lot of stars to align. Some teams need some additional coordination in order to be properly prepared for a productive Sprint Planning event. Therefore some as needed refinement gatherings can prove to be useful. Much like time-boxing events in Scrum and the simplicity principle of agile software development, use it as needed . . . don't make it an additional and wasteful requirement.

The idea of considering cost is certainly important and needs to be considered. I would always attempt to express it in terms of value, though I see how many organizations will react more actively to the "cost" viewpoint. Can more value be provided through simplicity? Is this a stop-gap measure which creates a temporary reduction in value while improvements are made? How much loss of value is acceptable? What amount of lost value will trigger action?

Thanks for another interesting read. Ditto the best wishes!

Side Notes
In addition to Scrum being "difficult to master," I often question if it is "simple to understand." Why? Because of the amount of misunderstanding out there. As Alistair noted, The Scrum Guide is written at the Ri level. I believe that those who need detailed instructions (Shu level), and those who can't or won't critically read the guide will continue to be baffled.

I had a senior quality analyst say that anything that the product doesn't do that the customer expects is a bug. My response was that Twitter has a bug that it doesn't allow 500 characters.

I probably should put more time into my response, but I believe it is enough to further the conversation.

Thanks again for participating, Alan! "Simple to understand." is an important point you raised, as well as costs and value. Maybe this sparks further discussions. "How much loss of value is acceptable?" could be an interesting thread itself.

Another fun term, "Watergile" https://www.scrum.org/Forums/aft/2061

That's cool, too. The latest I heard is "Anygile". I repeated Somegile so often, people invented something new.

Hello Marc,

let's assume there were teams out there that started implemtening Scrum and initially did stick to the recommended timeboxes for the Scrum events. Those teams ended up with a lot of meeting time every time when they close and start a new sprint. They inspected and adapted what could be improved and found out it is a good idea to move some backlog refinement activities to another point in time (let's say some days before the planning meeting and let's call it grooming ). One of the advantages is there is time for some clarification between the refinement meeting aka grooming and the planning. Conclusion: Reduce timebox for planning if you do backlog refinement meetings.

As you migh have guessed by now my personal experience with teams having "grooming" meetings is very positive - as it saves time and helps the planning to be shorter and more productive.

If there is no benefit in your groomings your Scrum team should inspect and adapt. Maybe also the wrong people took over Scrum roles in your case, but this is hard to judgde.

Keeping my fingers crossed for you

Cheers
Joerg



Cheers
Joerg

Hi Jörg,

thanks for participating!

Reduce timebox for planning if you do backlog refinement meetings.

of course makes perfect sense. I argued against additional events, especially if they're unnecessary and useless as they just cover up

Maybe also the wrong people took over Scrum roles in your case

.

I assume you only need some minor Product Backlog refinement and that's why your 'Grooming' is productive. Your Product Owner seems to be a good one and obviously listens to reason and lets developers help him make refinements.

Thx, you're welcome,

Marc