Daily Scrum – Person-by-Person or Story-by-Story?

Is your daily scrum conducted person by person? Do you jump back and forth from user story to user story because people working on the same story don’t speak one after the other? Does this context switching make it hard to understand the progress of that particular story?

I think the standard, and most obvious, way of conducting the daily scrum is to simply go around the room person by person. But, there is another way – going story by story through the sprint backlog.

I have tried both ways. When I was new to Scrum, it just seemed obvious that you would go around the room. This method will probably work fine for small teams or teams who take on a small number of user stories in their sprints. In other words, if there isn’t much context switching in the scrum, then going around the room should work fine.

But as your team grows the opportunity to switch context back and forth between stories will grow. And this is where the second scrum method, going story by story, can help.

With this method, you’ll ask who is working on a particular story and those team members will answer the scrum questions. That way you get a full picture of the progress on that story at once. Mike Cohn describes it this way:

For some teams, conducting the daily scrum by product backlog item can make much more sense than going person by person. When going item by item, someone on the team (often the Scrum Master) says, “OK, let’s talk about this product backlog item next. Who worked on it yesterday? Who is going to work on it today? And is anyone stuck on anything to do with this item?” When a team conducts its daily scrums this way, there is less lost context.

I used this method for a large Scrum team and everyone preferred it over the person by person method. However, I did notice some problems that you need to watch for.

The first was that the scrum can become mini status reports for each story. Because you now have multiple people talking about a story, it can be tempting to drill into details. Instead of each person answering the scrum questions and moving on, a discussion can start. So be careful about that and if necessary remind people to avoid status reports.

Another potential problem can occur if some team members are working on multiple stories. Those team members will have to get accustomed to only talking about the story being addressed instead of all their stories at once.  This isn’t a huge issue as long as they stay focused on the story currently being addressed.

Have you tried the story by story method? Let me know how it worked for you.

Scrum Master Mistakes

We all make mistakes as Scrum Masters. As we say “Scrum is easy to learn, but difficult to master.” We do our best and learn from our mistakes.

Mike Cohn talks about some mistakes he sees in his blog post “Three Mistakes Scrum Masters Make and How to Correct”.

I could have guessed the first and third mistakes he writes about. But, the second surprised me. Basically, Mike says the Scrum Master should not run the daily scrum.

I definitely have a take-charge personality and I do keep the daily scrum moving along by calling on people. And I think Scrum Masters need a leader personality in order to encourage the team to follow the Scrum principles.

I understand the desire to have a team which runs the scrum itself, but I’ve always seen my role as a facilitator. Now, I’m not trying to take over the scrum, but I’m making sure it doesn’t bog down, instead of being a silent observer. I regularly remind team members that they are sharing information for the benefit of the team, not for the benefit of the Scrum Master. Also, each Scrum team I’ve been on has had some remote members and calling on people was necessary at some point during the scrum.

However, I can see that a more hands-off approach will help the team become more independent and self-reliant. So this is something I will work on. I’ll ask the team to start the scrum and give the input without being prompted.

I can see another possible benefit. I mentioned earlier that the information shared in the scrum is for the benefit of the team itself. I tell my teams that the scrum’s purpose is to plan the work for the day so it supports the completion of the sprint goal. Although, I struggle to drive that ideal home to some team members. Sometimes input for the scrum can be too brief and not very helpful, or sometimes it’s more like a status report. Maybe a more team-driven scrum will help improve on this.

Let me know your what you think and what works best for you.

Today I read… (8/10/2017)

Reasons to Estimate During Planning Poker with the Whole Team   https://www.mountaingoatsoftware.com/blog/why-the-whole-team-should-participate-when-estimating

Three Mistakes Scrum Masters Make and How to Correct Them   https://www.mountaingoatsoftware.com/blog/three-mistakes-scrum-masters-make-and-how-to-correct-them

Today I read… (6/23/2017)

4 Daily Scrum Tips for Product Owners and Product Managers – DZone Agile  https://dzone.com/articles/4-daily-scrum-tips-for-product-owners-amp-product

How totalism works   https://aeon.co/essays/how-cult-leaders-brainwash-followers-for-total-control

 Today I read… (6/19/2017)

Happy 20th Birthday to “Managing the Design Factory”


Better Products through Science!

This past Saturday at Houston TechFest 2016 during an Agile development panel discussion, I was reminded of one Agile technique that we might not practice often enough. That is the use of the scientific method to help us create the right features for our customers.

Wikipedia says:

“The scientific method is an ongoing process, [in which we] come up with questions about the things we see or hear … and develop hypotheses [which can be] tested in various ways [with] experiments that gather empirical data. [The original hypotheses] may require refinement, alteration, expansion, or even rejection.”

That should sound familiar if you practice Agile and/or Scrum. It’s an iterative approach to learning and can be applied to how we meet the needs of our customers.

The Lean Startup is a book by Eric Ries which describes approaches new startups can use to build the right products for their customers. A central topic is the use of the scientific method to achieve validated learning.

Ries says in his book:

 “…We need the scientific method. In the Lean Startup model, every product, every feature, every marketing campaign – everything a startup does – is understood to be an experiment designed to achieve validated learning.”

Of course, we don’t all work at a startup. But we can apply some of the Lean Startup thinking to new products, projects, or features.

We use validated learning when we are uncertain about what to do or build. When we can show that we have discovered valuable truths about the needs of our customers by using empirical information, we have achieved validated learning. Ries says “It is the principal antidote to the lethal problem of achieving failure; successfully executing a plan that leads nowhere.”

Ries suggests we should add small pieces of functionality to our products then gauge our customers’ response. The pieces of functionality are experiments to test our hypotheses and gain quantifiable outcomes. We need to know if customers want the functionality or not. The empirical results of these tests help us achieve validated learning.

Again, this should sound familiar to anyone on a Scrum team using an iterative approach. We can design our iterations to help us understand what the customer wants and then get their feedback to make sure we are on the right track.

We also need to remember that our customers might surprise us. Failure to meet their needs is not bad when we work in short iterations. It just means we need to rethink our plans based on what we learned. Ries says, “This is one of the most important lessons of the scientific method: if you cannot fail, you cannot learn.”

How often do we work on a feature only to realize we’ve put so much time into it that we can’t afford to fail? Scrum allows and helps us create small pieces of functionality, so we should incrementally create features to determine if they are really needed. Use these increments as experiments to validate or refine our hypotheses.

Ries writes about an executive who asks his development teams to answer the following questions:

  1. Do consumers recognize that they have the problem you are trying to solve?
  2. If there was a solution, would they buy it?
  3. Would they buy it from us?
  4. Can we build a solution for that problem?

Many times we skip straight to the fourth question. Any assumed answers to the first three questions can result in an incorrect answer to the fourth, which leads to trouble.

This is the question that popped into my head during the panel discussion:

How much of what we are doing is based on customer feedback versus what the project plan tells us to do?

Let’s find ways to focus on customers and experiment to achieve validated learning.

Make Backlog Grooming More Efficient

Backlog grooming is necessary for any Scrum team. But often our teams get bogged down because our grooming sessions are inefficient or ineffective.

Do you find that you aren’t grooming as many stories as you would like during grooming sessions?
Do you regularly struggle to have enough stories ready for sprints?
Do your stories lack good acceptance criteria?
Do you regularly miss key details which effect the success of your user stories?

In situations like this I follow one rule – If something isn’t working for the team, do something else. Find something that does work.

Backlog Grooming is a Pipeline

Backlog grooming acts like a pipeline to supply user stories that are ready for sprints. Stories enter the pipeline needing additional details. At the end of the pipeline they should meet your team’s Definition of Ready. In general, they should have a well understood title and value statement, have good acceptance criteria, be properly sized and estimated, and have tasks.

Teams which are new to Scrum may think of grooming as something which is only done in grooming sessions. I know I did. However, my team became more efficient once we started thinking of grooming as a continuous process.

Now, I’m not saying that we should spend all our time grooming. I just want you to see that backlog grooming doesn’t need to be restricted to grooming sessions and that anyone on the team can work to improve story details at any time.

So how do we make the grooming pipeline more efficient?

Be Prepared

A big hindrance to effective grooming is being unprepared for grooming sessions. Trying to groom from a backlog that isn’t prioritized, trying to groom stories which have very few details, or creating new stories during grooming sessions is not efficient.

How can the Product Owner (PO) prepare?

Keeping the backlog in priority order is the responsibility of the PO. This allows anyone to review the most important stories at any time.

Teams are more efficient when the stories they are grooming have a reasonable amount of detail. In my experience, it’s hard to create stories on the fly in a meeting. I believe any story presented for grooming should have a title, value statement, and acceptance criteria (unless the story is an epic or feature). This gives everyone the same starting point and reduces discussion due to different interpretations. Basically, the PO is anticipating and answering questions before they are asked.

The PO can also provide an agenda with a list of stories to cover in the grooming session. The agenda keeps the team focused on the important stories and also gives the development team the opportunity to review those stories beforehand.

How can the development team prepare?

The development team should do things which allow them to better understand and estimate the stories. As mentioned earlier, they can review the top priority stories beforehand. Come to grooming sessions prepared with questions or comments and add them to the stories for everyone to see.

Developers on some teams spend a few minutes each day reviewing the top priority stories. Again, the PO can help them make this effort productive by keeping the backlog prioritized.

I’m a big believer of referring to code to better estimate stories. Of course, we don’t want to get too deep into implementation details while grooming. But, a general understanding of existing code and how it will be modified or used will help us create better user stories.

Be Focused

We all need to stay focused during our grooming sessions. I understand that can be hard if discussions get too detailed or the meeting drags on. My new phone gets more tempting as time goes on and my inbox starts to fill. However, it is important to be courteous to everyone in your grooming sessions. Put the phone down, the emails can wait, stay focused on grooming.

How do we gain better focus?

The PO facilitates the sessions and keeps the discussions focused on grooming the stories on the agenda. The PO should also time-box the grooming of each story and decide when to move on to the next one.

Grooming is about getting answers to questions. Therefore, bring the things you need to answer those questions to your sessions. If you need to refer to documents, UI mock ups, or code, have them available. Bring your laptop so you can refer to them. Making assumptions without verification is a major cause of unsuccessful stories.

Don’t let your sessions run too long. It’s best that they are no longer that an hour because it’s hard to keep people focused for much longer. It’s even possible to have highly productive sessions in only 30 minutes.

Work between Grooming Sessions

As I’ve said, it’s important to recognize that grooming doesn’t stop at grooming sessions. During any session, you will probably realize more work is needed to fully groom some stories. Some of this work can be done prior to the next session or next sprint planning.

What can we do between grooming sessions to improve user stories?

The PO should be doing the usual things – adjusting backlog priorities, improving story details, and adding or improving acceptance criteria. Essentially, they are improving stories based on the discussions we had during the sessions.

The development team can also improve stories between sessions. Many times during grooming, we raise questions which require research or to review code to find the answers. If that can’t be done in the grooming session, assign someone to do this work before the next session. First, record the questions in the story. Then once someone finds the answers, also add them to the story. This makes the information available to everyone, we won’t forget it, and it’s ready for the next session.

The development team can also add tasks to stories between grooming sessions. I’ve found it can be hard to add tasks as a team because people think about tasks differently. Sometimes it’s more efficient for one person to add the tasks and then validate with the team later in a grooming session.

The development team will usually need to help the PO in creating and grooming technical user stories. This might include writing the initial acceptance criteria. This work is also best done before the grooming sessions.


As we groom the backlog there are a couple of important things to remember. First, only the PO can change priorities in the backlog. Members of the development team might act on their behalf, but the PO must be involved in any priority changes. Second, the PO must be involved in any changes to acceptance criteria.

Good Enough

The key to good user stories is that they have enough details so we can successfully complete them in a sprint. We aren’t trying to write the perfect story because we can’t be forever grooming. We do just enough grooming so our stories are good enough.