Difficulties with grooming and planning meetings

It is necessary to have estimates in place, because otherwise it is not possible to track velocity or plan the next sprint.

Estimates and tracking Velocity are not necessary to plan the next Sprint. Some teams may find estimation helpful, for various reasons, but it's not the only way. Some teams try to decompose work into roughly equal sized pieces. Others break down the work into tasks and are good at looking at the tasks and having a good feeling that the work will or won't fit into the Sprint, based on capacity. Even if estimation is performed and adds value for the team, there are different units of estimation to be considered.

I'd recommend taking a good look at why and how you estimate to make sure that what you're doing makes sense to the team.

But we find ourselves racing to finish estimating stories during sprint planning on a Friday, before the sprint starts on Monday. People are keen to finish their work for the week and get a beer, and the act of entering estimates is perceived as a waste of time.

This seems to be a scheduling problem. There are a few considerations here.

Friday is a bad time to hold Sprint events. People are mentally tired after working a full week. They want to get out of work and start their weekend and have time for themselves and the things that they want to do. When people are tired, they make mistakes, get sloppy, or just lose interest and focus. Friday (and Monday) are also common days for people to take off to have a long weekend and (depending on your location) the company may be closed for holidays.

I would recommend moving your Sprint events to Tuesday, Wednesday, and Thursday. Take a look at how you allocate Sprint Review, Sprint Retrospective, and Sprint Planning. There are different ways to do it, depending on the team and product. You'll need to consider synchronization if you are working with multiple teams on a product or multiple products in a portfolio.

As a corollary to the above issue, grooming sessions are simply presentation of the upcoming week's stories, with a sense of urgency to plow through everything. (The backlog is massive, ungroomed, and cutting it down is not seen as a priority.)

Notes from technical conversations are not properly entered into Jira, which means the insights and decisions are forgotten and discussions are repeated at later meetings. But it is not so simple to just assign a scribe for the meeting - in order to take good technical notes, one needs to have a thorough understanding of the technical issues. Only one or two team members are experienced enough to follow every single conversation; yet those people also happen to be poor note-takers.

Discussions are quickly dominated by the longer serving term members (who also happen to have loud, dominant personalities). They race into discussing technical requirements before the newer team members have a chance to understand the story being presented. This means the newer team members are often sitting around without being able to provide much input.

On the flip-side, if the newer team members do speak up, it then takes a long time to explain to them the background to the story. Overall this is (rightly) perceived to be a bit of waste of time, because it is not necessary for every single team member to understand every single story. Not to mention the less-technical product owners also sitting around with eyes glazed over whilst the team talks tech.

These strike me as very related.

It seems like you are holding Product Backlog Refinement meetings. Are you trying to do all of the refinement in these meeting sessions? If so, have you considered not?

In the Scrum Guide, Product Backlog Refinement is not an event like Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. I fully believe that meeting, as a team, does make sense. It gives the Product Owner a chance to present Product Backlog Items to the whole team and get feedback or questions. It also gives the team the ability to regroup on each Product Backlog Item.

The best refinement happens outside of the meeting, though. Individuals or small groups can work on getting a deeper understanding of the Product Backlog Items and identifying the technical work necessary to realize them. These people may work with the Product Owner as part of this process. This is a great way to help newer team members come up to speed - pairing a more experienced team member with a less experienced team member can be a valuable teaching/learning opportunity without needing the whole team to be involved in the refinement of every single Product Backlog Item.

So, short story: get refinement out from meetings and use team-wide refinement sessions to regroup and review and align on the state of Product Backlog Items and the Product Backlog as a whole.

Can you clarify:

• what you mean by a “Scrum Owner” role,
• why multiple Product Owners appear to be present in certain events, and
• whether a sense of urgency for change is being communicated, and if so how and by whom.

It is necessary to have estimates in place, because otherwise it is not possible to track velocity or plan the next sprint…

a sense of urgency to plow through everything…

Notes from technical conversations are not properly entered into Jira…

You paint a picture that is heavily process and output oriented. There is no mention of customers or users, nor about accountability for outcomes, or a notion of having an impact on the world.

Could your organization possibly be suffering from Zombie Scrum?

People start to advocate for behaviours which are against the Scrum ethos (i.e. simply having smaller adhoc meetings with the senior people only).

It's important to understand the motives of these people. Could they be embracing continuous improvement? Perhaps they've inspected the current approach and want to adapt it into something more effective.

In short, are they good people trying to do what they believe is right, or are they trying to improve the meetings for their own self-interest?

I suspect your problems are deeper than having wasteful meetings. Perhaps your organization rewards individual performance over team performance, maybe team members are unwilling or unable to adapt their behaviours or routines, such that this moment when the whole team are together just exposes the underlying problems.

If you haven't done so already, I think you should find out what your team believe in. What are their values/beliefs/principles, and how strongly do they believe in them? Will they stand up for what they believe in even when they're stressed or constrained by the reality of the organization you work for? Are they willing to compromise once they understand that team mates have different views?

If you understand that about your team, you stand a much better chance of solving problems together; and if what you learn is that the team don't share your values, it's good to know that early, so you can decide on the right course of action.

Hello CB Pearson. What you are describing is pretty common in organizations where staff have not been trained on Scrum so they don't know how to apply it to improve their work and the Product.

If you're in a position to influence decision-makers, you should convince them to either have everybody on the Scrum Team trained by a Scrum Trainer (on-site or off-site) or to bring in an Agile Coach with a background in Scrum (not just an Agile Coach who has taught scaling) to get everybody up to speed.

What is your role? Are you a Scrum Master or a Product Owner?

Have you attended a Scrum training for a Scrum Master? I would advise you to attend an in-person training so you are clear on Scrum principles which will help you help your Scrum Team(s).

1) Based on the objective or the Sprint Goal, the Development Team should feel empowered to select the Product Backlog Items that they forecast can be built into a Done increment. I ask Development Team members to select these Items but I don't burden them with the administrative task of assigning story points or t-shirt sizes.

2) Product Backlog Refinement should be ongoing and happening often. For a two week Sprint, the Product Owner and the Development Team members can meet for an hour every other day (three days per week) to add detail, estimates, and order (Scrum Guide). If this is not happening, how will Product Backlog Items get refined enough to get selected?

3) I don't advocate for tools. Tools don't make Scrum. I have seen people spend more time on learning their way around a tool and on administrative functions than on actual work. I use Excel Online and share the spreadsheet with everybody so they can add notes, details, etc. There are times when my client will insist that I use the tool that they've spent a significant amount on acquiring. Do you know what happens in those instances? The Scrum Team will keep the Scrum Board and related items updated in the tool and then will replicate those updates in an email and then all collaboration happens either through e-mail, instant messaging and in-person. The tool just becomes a way for management to keep an eye on productivity and to pull reports on the work performed.

4) & 5) This is where a Scrum Master steps in and helps facilitate the conversation. 

Scrum events are not meetings. They are there to help the Scrum Team and others inspect and adapt. People need to talk to each other so they can solve problems. Scrum is providing you with some time-boxed events to do that so unnecessary meetings aren't happening.

To add on the other suggestions: I wouldn’t take 4 & 5 too lightly.

Teach them that the PO explains the story first before discussions. Make sure everyone understands what needs to be done. The Scrum values are very important for any team to work. 

What worked for my team is moving up the technical discussions to the sprint (technical decisions change anyway if you refine for more than one sprint) as an extra benefit our teams collaboration during the sprint increased and became a more self organising team.

As suggested moving the sprint to another day could work but maybe you could ask them how they would resolve the issue.  

Hi, thanks for your insights everyone. A lot of food for thought.

Just to clarify a questions that came up: The terms "scrum owner" and "multiple product owners" is just me using the internet too late at night. I meant "Scrum Master" for the former. And there is definitely one product owner, but there are two people from the product team who usually come to the meetings. The product team have a sort of business analyst / account manager function, and there is a senior person and a more junior person, with the senior one taking on the Product Owner role.