Skip to main content

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

Last post 08:46 am August 31, 2016 by Marc Smeets
6 replies
04:35 pm August 27, 2016

[This is a follow up to https://www.scrum.org/Forums/aft/2043, https://www.scrum.org/Forums/aft/2176 and https://www.scrum.org/Forums/aft/2187 and probably the last part of this series.]

I was just confronted with a new fashion I already dislike a lot. 'Grooming', I was told by the worst enemy of Scrum one can imagine, an (this special one) Agile Coach, will help the Scrum team solve the 'Chaos Monday' issue (so called Sprint Planning, actually just committing of items forced upon the developers).

Alright, but if the Product Backlog is fine, there's of course no need for any additional event and the Scrum Development Team can just pull the right items for their Sprint Backlog to come up with an Increment. 'Grooming' is expected to enhance an obviously weak Product Backlog, which basically means making it less crappy. It is of course expensive, as it consumes quite some Product Owner and Development Team hours, reducing Sprint capacity.

I know Scrum is kind of a soft (agile) approach to software development, but I still haven't lost my killer instincts, smell weakness and fear and of course go after anything that hurts my project. Is it agile to helplessly watch everything going down the drain? I am convinced broken things need to be fixed, even if it hurts and one doesn't necessarily make a new friend, not groomed.

If your Product Backlog is far from perfect, then you just need another / better Product Owner. Period. That's just it. A crappy Product Backlog is the result of incompetence at work, nothing else and therefore no additional and (once again!) expensive event will help. Do agile people really ignore costs? I don't! If anyone here likes 'Grooming' instead of having an able Product Owner who gets his job done, who's gonna pay for it? The stakeholders? Stakeholder's clients?

How does anyone expect 'Grooming' to make any difference, ceteris paribus? If the Product Owner is unable to write proper user stories and acceptance criteria, doesn't listen to reason and refuses to learn, no 'Grooming' on earth will help. Host as many 'Grooming' events as you want to, given you've got nothing else to do during your Sprint, this still is like a game of pick-up sticks, played by lunatics (thanks Yulia & Lena for this phrase!). "Against stupidity the gods themselves contend in vain", remember?

So inventing 'Grooming' will actually hurt your project as it just keeps an unable Product Owner on board instead of making a necessary change that will help.

ScrumWaterFail (thanks, Alan https://www.scrum.org/User-Profile/userId/190703), Somegile and the like cause nothing but trouble. “Scrum is difficult to master” really seems to be the case for quite some companies, there are lots of complaints here from many Scrum Masters. Maybe sometimes too difficult, indeed.

Survival of the unfittest at the expense of fit ones (developers wading through Product Backlog crap) and of course stakeholders will end in disaster. Be careful what you're flirting with...

Software development is serious business, stakeholders and eventually clients pay dearly for our work and I'm not one to waste dear clients' money.

Good luck with your projects, dear Scrum Developers, Scrum Masters and Product Owners who can tell a change request from a bug. I know there are some out there!

Yours,
Marc Smeets


01:50 pm August 29, 2016

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.


02:25 pm August 29, 2016

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.


12:10 pm August 30, 2016

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


01:06 pm August 30, 2016

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


08:25 am August 31, 2016

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


08:46 am August 31, 2016

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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.