As a product owner, I love stand-ups.  I love discovering what information I need to provide to help team members make progress on a user story. I love the way they help team members quickly discover issues that will prevent them meeting the conditions for satisfaction. I love the way they act as a catalyst for the team to work together to solve problems. I love the way it gives less experienced members of the team exposure to what senior developers are doing, and the opportunity to shine in their own right. And I especially love hearing about where development is up to – knowing that it means come sprint review we’ll have exciting new functionality to review as a team.

But I have to admit – not everyone else on the team loves them.

Some team members are skeptical of the value they bring. They say they are an interruption to their coding flow. Or that they are just unhelpful status updates. Or that they aren’t being used the way the scrum process intends them to be used.

I think that sometimes these criticisms are completely fair. No team is perfect. No stand-up is perfect. But I also think even a bad stand-up is better than no stand-up.

To be clear, here’s what I think makes a good daily stand-up meeting:

• Transparent: The items on the sprint backlog are visible to everyone so participants can understand what’s left to do
• Focused: Story-centered review of progress towards completion, so team stays focused on actual sprint goals
• Predictable: Same time every day so everyone can easily plan around it
• Short: Identifies any issues and resolves them in follow-on break-out sessions so those not involved can get back to work quickly
• Inclusive: Whole team is present so everyone knows what is happening and can learn

Done well, stand-ups are a powerful and I think essential catalyst to ensure the team achieves it’s potential for cranking out amazing software at an impressive pace. Done poorly, I think they can still achieve some of the important “so’s…” in this list.

But writing this down makes me realize there are some things we could certainly be doing better at. Here’s how I’d rate our current scorecard.

Predictable: We are good at this. Stand-ups are at 10AM every day. Most people are on time, most days. 9/10

Short: I have heard about teams that have daily 1 hour “stand-ups” – ours usually go for 5 to 10 minutes, never more than 15 minutes. This feels about right to me. 9/10

Inclusive: All local team members are present, but remote team members are left out. We have tried including remote team members before, but now we have separate daily scrums for them with key local team members. It’s a compromise, but I think we get a pass mark here. 6.5/10

Transparent: We have a largeish monitor displaying the Jira sprint backlog – but I think in practice this is one area where we fall down. No-one except the one or two people standing right next to the monitor can read it at all. And I think this discourages participation. This is a fail that I think we have to fix. 4/10

Focused: I think our problems here stem from our sprint planning process. In the last couple of sprints (we are currently fairly early in what we expect to be a major release), we haven’t always had the courage to write down our sprint aims as end-to-end pieces of user-targeted functionality with clearly demonstrable conditions for satisfaction. In other words we have had a lot of tasks on the backlog – as opposed to user stories. By their nature many of these tasks have been the province of individual developers. So rather than feeling like several people are pulling towards, say, “publishing a blog post so others can read it”, it feels like we’ve got  individuals on the hook to get the “Publish button to save the contents of the edit control to the server”. The result is that it is all too easy for the daily stand-up – which keeps the overall sprint objectives top of mind for the team – to easily lose focus of the bigger picture. Still, we aren’t universally bad in this area, so I’d give us 6/10 on this.

For those who like to keep score, I make this 34.5/50 on my super-scientific measures. So, it feels like we’ve got some work to do.

Next time I’ll talk about the sprint planning process, probably the most challenging part of a scrum-inspired development cycle. There’s lots of challenges in planning – but I think the biggest one is deciding on and describing the slices of functionality that actually make sense to try to deliver in a 2-week (or whatever length you have) sprint.