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.
Ecphorize 
Couldn’t agree more. Good article. I like the 5 points of what makes a good stand-up meeting.
At the moment, I work in a startup and our developers are scattered across the country. Our standups on Skype go for a little longer than 20 minutes. Even though somedays I find it interruptive of my ‘optimum coding time’, I can’t see how the team can function without it as transparency is absolutely crucial. It’s only when that element is missing, you start to see how important it is. Like you said. Since it’s predictable, it’s always easy to work around it – I some how managed to get my ‘optimum coding time’ to another period. I guess that level of transparency is also necessary when there’s a lot more crossover in work. I find it helps to think of what other people in the team need to know from me, ie. what pieces of information is valuable to them instead of just saying “I fixed a bug or working on X”.
Since everyone is on their own computer, it makes it easier for everyone to view the jira sprint and in a way it constantly emphasis our sprint goal.
Every team is different : The reason why our standups go longer than 5 minutes is mainly cause we do a bit of quick online planning poker at the end of huddle with our product owner, to determine whether anything needs to be urgently addressed and moved into the sprint or just moved into backlog. So nothing remains in triage for more than a day. Anyway, the ‘planning poker’ of our planning meetings is kinda ‘customised/absorbed in the end of the huddle’, instead of having 2-3 hour planning meetings in one go; or having someone to do triaging. It also makes our huddles hands on. We still have planning meetings, but it’s way shorter.
TL;DR – Huddle meetings can be extremely valuable in some cases. It’s a good place to assimilate information.
Thanks for the perspective “anonymous” K. 🙂 Interesting to hear about an online huddle process that is allowing the team to stay on top of the backlog in an effective way. I have to admit, grooming is a process we are still haphazard with. It’s particularly hard early on in a major release cycle when there are a lot more unknowns than knowns. We actually aborted a sprint earlier this release (it was going to be the first real sprint) because there were too many unanswered questions about release objectives.
My experiences, particularly post team awesome is the delivering bags of tasks rather than usable things is the norm in scrum. One example project I was working on had 5 scrum teams and I’d go to the scrum of scrums and it would be all these tasks got done, everything looked green, burn downs showed managed progress, great! However lots of late pivots and discovery of feature knowledge as you ended up with these bags of things but the focus on the actual customer value and the reason for doing it got lost. With my lean cap on I think one of the problems i’ve seen is that instead of having a time box that is sized to deliver the minimum valuable story to learn from, there’s regular fixed time boxes eg 2-3 weeks and tasks get pulled down based on what fits. One technique i’ve seen that breaks this is always making sure that the demo at end of sprint happens. Sometimes it may be a set of test case for technical things, but forcing every sprint to get up there and demo through what was achieved before it’s considered done helps focus the brain on delivering usable things I think. Gives good team feeling of lots of little wins and we all know software’s a game of millimeters 😉
Also what did you rate your standup alarm music as you’ve got to have that to kick off a great standup right?
We are constantly striving to not have major pivots late in the cycle – though some are inevitable, I think, given that we are aiming for big discoveries where possible. I personally find user stories key (rather than tasks) for combining the expression of sprint objectives with user value. I think the constant focus on the “why” of the user value helps avoid that trap.
My passion for user stories isn’t universally shared, I think it’s fair to say. The main reason being that it can become artificial to construct a story that “fits” within a single a sprint (the user value gets diluted by putting lots of conditions on what is actually expected to work). But I am increasingly convinced this doesn’t need to be a problem, and that in proof of the adage “the work always expands to fill the available time” if you don’t aim a bit high, you always end up under-achieving. Ideally you’d do this with lots of atomic user stories that the team could get satisfaction from completing as many of as possible during a sprint. But in practice I sometimes think a slightly vaguely worded “shoot-for-the-moon” user story can challenge people to see how far they can get.
BTW: No standup alarm music I’m afraid to say (laptop speakers seem to be getting more pathetic these days). Just a team mascot: the travelling zombie – who is quite good at propelling himself towards recalcitrant team-members that are time-awareness challenged.
PS: Our sprint reviews are usually pretty good for looking at usable features. Sometimes it becomes about looking at the “Proposed UI for the X interface” – but more often than not we have real product functionality to demo and discuss.