I want to address a question that I got recently and that comes up every month or two. I was recently emailed the following:
Most of our teams complete 10 or more user stories per sprint. When answering the 3 questions in the daily Scrum, it was clear what each person was working on, but it wasn’t as clear how each story was doing or when a story was in trouble. For example, if no one worked on a story, problems with that story aren’t visible because no one mentions that story during the standup. What we’ve started doing is conducting the daily standup story-by-story rather than person-by-person. Now it’s very clear how each story is progressing, but difficult to figure out what each person is doing. Some people work on multiple stories and others may not even speak up in a daily Scrum.
One possible solution to this common problem is that these teams are doing too many product backlog items per sprint. Based on data I analyzed on successfully finished sprints, I determined that a team should average around 1 to 1-1/2 user stories (product backlog items of any sort, really) per person per sprint. So, a six-person team should get somewhere around 6-9 user stories done per sprint. Teams doing shorter sprints (one or two weeks) should be at the low end of the range; teams doing three- or four-week sprints should be at the upper end. This means that coincidentally teams with longer sprints do slightly larger user stories in their sprints.
I hate that the answer I got was around one user story per person in a sprint because that makes it sound like each person grabs one user story and works on it alone for the duration of the sprint. Nothing could be further from the truth. Expressing the number of items in terms of the number of people on the team is just an obvious way to state the result: more people, more user stories. I want to reiterate though that the result is not for each person to do one user story per sprint alone.
Another solution to the problem above is to conduct the daily standup in front of a physical task board and have people point to whatever they are working on. I always prefer to do this whenever possible. I frequently ask the speaker to “Point to what you’re working on.” Assuming a well setup task board this will show me the user story that the task relates to.
Another solution is to designate a “point person” for each user story the team plans to work on in the sprint. This person is responsible for knowing if the user story is moving along appropriately. The person is essentially a “story owner” but we’re talking about 2-5 minutes a day of extra work. This isn’t a heavyweight new responsibility. The person may or may not be the primary contributor on the story; it doesn’t seem to matter.
Another possible solution could be to look at the sizes of the teams involved. I find the ideal team size is 5-7 people. Standard agile advice seems to be 5-9 is the right size. When possible I try to stay on the low end of the range. If the team is more than 9, it is easy to lose track of what people are doing.
Finally, most teams do the daily standup per-person, but some encounter the problem described here and discuss things story-by-story. Not all teams need to do it the same. If you’re in an organization with even a handful of teams, I would randomly split them and tell some to try person-by-person and others to try story-by-story for a full sprint. I’d get everyone together afterwards for a short cross-team retrospective and let people say how it went. Hopefully teams could hear the results of other teams and then make a good decision about what to do next.
Tags: daily standup, sprints, teamwork
At first sight i like “Point to what you’re working on.” approach. May be being a dev i am being a bit biased.
“Point Person” seems we are heading for another hierarchal structure.
Hi Ravindra–
I completely agree. I’ve never personally liked having a point person assigned per story, but I have seen it successfully used by teams. I don’t think it leads to a hierarchy because the person doesn’t have any authority. In fact, the teams that use this technique most effectively more or less randomly pick the point person–he or she may have no work on that particular story at all. I used to think this was odd (I guess I still do a little) but perhaps that helps prevent it from creating hierarchy problems. My issue with it is that it changes communication paths.
Pointing to what you’re working on is by far the best and one of the big advantages to using a taskboard and conducting daily standups in front of it.
From my point of view the need for a story-by-story standup shows that the taskboard isn’t showing the real efforts needed to fulfill the sprint goal. Thus it leads to some dangers like people working on the tasks they find important – which are not necessarily tasks the team finds important. This somehow annuls the team’s priority.
To see when stories are in trouble you only need the sprint backlog – which clearly shows the order of the stories – and the burn down chart. If the team works more or less sequential on the stories (which means no more than 2-3 stories in progress at the same time) than you can easily see on the burn down chart if one of these 2-3 stories is in danger.
We always run it so that the first person to raise the topic invokes the story discussion (and is the pseudo-point person for that standing meeting). Any people who haven’t spoken yet are expected to chime in on the discussion around that story. As we go around the room, certain people will barely note what they don’t need to raise because it was covered already. This saves time by consolidating the story discussion into one chunk and helps the group remember that they are working as a team towards business value (represented by stories, not their individual tasks).
Since we start with a different person every day (random volunteer) and go in a different order (random room standing)… this seems to solve Ravindra’s concern.
I agree that “Point to what you are working on” is a great approach, but becomes very difficult when you have remote members. I’ve seen tools like VersionOne and others try to overcome this with electronic cards, but it’s not the same without the tactile experience.
Excellent point, Sebastian. Yes, this whole situation is probably indicative of other troubles within the team. I think you’re suggesting an additional possible solution–have the team work on no more than 2-3 stories at a time. Not all teams do this.
Additionally, I’m not sure I agree that the sprint backlog “shows the order of the stories.” I’m not a big fan of prioritizing stories within the sprint. The team commits to delivering them and should commit to all (or shouldn’t bring some into the sprint).
Great suggestion, Kevin. Thanks. I forgot that I have seen a couple of teams so this approach of nominally going person-by-person but shifting gears each time a story is discussed the first time to discuss it more thoroughly.
By the way, as I read the responses to this topic, I’m struck by how the ability for all these different teams to do all these different things is the real strength of Scrum or agile. We’re all doing something a little different yet for the same reasons. It’s a definite strength of the process to accommodate such variety.
I like the switch of focus to the work as opposed to the person. I’m thinking about something you actually said a while ago about the daily standup being more about commitment than status.
Does switching to a story focus help more with commitment than a person focus?
I’ve also recently learned more about Lean daily start-up or daily production meetings. Joe Ely says that they’re more about improvement than status.
Does switching to a story focus help more with improvement than a person focus?
Hi Jason–
First–thanks for commenting; it’s good to see your name as I haven’t heard from you in awhile.
Great point–I hadn’t thought about it before but I suspect you’re right that a story focus helps with commitment. But probably more so from experienced, well running teams than new ones. On new agile teams I find it too common that there is a person or two who is either too shy to say much or doesn’t want to say much because he or she wants to hide that they didn’t do much. It’s harder to detect this with a story focus.
I don’t know if story focus helps with improvement. I don’t think it will but I will say that most teams miss the opportunity to use the daily scrum for noticing and suggesting improvements. It’s a shame that a lot of teams try to do all process iimprovement in the retrospective. A lot could be accemplished mid-sprint. While I agree we need time at the end periodically to step back and look at the process, a lot is missed by only doing this. I’ve read a couple of articles and a book lately on military “after-action reviews” and such. One thing I learned is that the After-Action Review is the most visible part of the learning process but it is not the only part, and a more continuous learning is desired.
–Mike
We did our daily standup in front of a physical task board and it worked pretty well. You could easily see in which progress the story was.
If you are working on a story and you run into a problem your are not able to solve you hang up a blocker card (and of course assigne your problem to the scrum master). During the standup everyone immediately sees the blocker and you can talk about it.
Hi Steph–
This is indeed one of the biggest advantages to using a task board. I’d encourage any team that is collocated to try one out. It improves communication and solves lots of small but potentially troublesome issues.
I am coaching a team that uses “person by person with point to what you are working on.” We start daily scrum with a person randomly picked. It helps with avoiding any opportunity to hide behind story owners (which we have). Story owner is a voluntary role (no implication of hierarchy) and collaboratively picked by the team during the planning meeting. The owners are expected to coordinate and facilitate work on the story. What we found that without a designated owner sometimes team misses things (don’t see the forest).
I like the “blocker card” idea. I need to introduce this to the team. We usually have an impediment board. We also post the Burndown chart (printout from ScrumPad tool) next to the task board.
We had a different issue with daily scrum though. Nobody mentioned it here. So, I am curious whether anybody had similar We found that people will not pay attention to (tune out) others if he or she is not involved with the story. As a result, we felt that daily scrum loses some of its effectiveness. So, we tried to have people speak for somebody else instead of himself/herself. 10 mins before the daily standup, the team will randomly pair up and exchange information so that they can answer the three questions on behalf of the other. It worked great. However, the team could not continue to do this…:-)
Syed
http://blog.syedrayhan.com
Hi Syed–
Excellent thoughts; thanks for sharing them here. I think you’ve hit on the big problem with story by story, which is that it is more likely that what is being said will be irrelevant to another attendee. I don’t mean the person shouldn’t listen but it’s harder at times to do so when I “know” that they are talking for the next 3-4 minutes about a story I’m not on. It’s human nature for concentration to wander.
I like your idea of reporting for someone else. I put things like that though in the category of “training aides” a team can use for a short while. It helps them learn to listen to others but isn’t sustainable long term.
One attention-getter I’ve used was this: I got twenty $5 gift cards from Starbucks and asked one random question at the end of some daily scrums. “OK, who said they need to meet with Bob in Marketing.” Winner got a card. I didn’t do it every day–just enough for the team to know to pay attention. The pride of winning was more than the value of $5 as that isn’t quite even a coffee.
Someone I told this to later told me he painted a rock and whoever got the quiz right displayed the rock until the next quiz. It was more a joke than anything else among the team but they did pay more attention.
–Mike
Mike,
I like the random quiz idea. I’ll have to try that.
Syed
My Blog
We try to make our teams be focused on only 2-3 stories at the same time rather than starting everything at the first day of the sprint and finishing (if they succeed) all the stuff at the end. It is very to do so, but I’m sure we have to.
Ideally, in a perfect world, a team would be able to start only ONE user story, complete it an then start another one. Beside this idea of “not starting to much tasks at the same time” there is the lean approach, kanban and theory of constraints. We can translate this concept to “make done first the things you started the earlier” or “reduce the cycle time = the time of realization of the user story by the team”. That induces a kind of priority between each user stories of the sprint.
Recently, I got the idea to reformulate the “third question” (“do you have any impediment?”) into
“what are the impediments that are stopping the earlier started user story? (The one that needs to be completed before the others)”.
This question seems to be very useful, because she points out exactly the things that are taking time from the user story point of view (for instance: a resource is not available, an existing technical issue, something to do but nobody cares, etc..). It seems that this practice fits a lot your approach to move from a “person-to-person” point of view to the “story-to-story” one. Hope that can help.
Hi Emmanuel–
I can definitely see how asking the third question can be very helpful in a situation where a team is trying to get out of the bad habit of working on too many things at once. So it’s great for how you’re using it, but I wouldn’t use it for all teams in all situations. Consider a case where nothing is blocking me on the current story, but I know that for the next story I need to meet with Tom so I’ve emailed him and said “Can we meet in the next few days?” and he says “Go away! I’m busy for 8 weeks!” Well, that’s an impediment that wouldn’t be answered via this question.
I want to comment also on the idea of “work only on one story at a time” which is sometimes a good idea but I’ll save that for a new blog topic next week. Thanks for the idea.
One way to deal with the “who’s working on what” question is to print out little avatars for each developer (either a picture or a character created with something like http://www.sp-studio.de/ works well, or corner of post it with your initials on will do) and stick them onto the story that each person is working on. This means you can immediately see what from the board not just what state the stories are in, but also who’s working on what.
Whenever people re-pair, or start something new, they move the card and stick the avatars on.
Doing the stand-up in front of the board then gives a couple of extra benefits:
1. If a card doesn’t have any avatars on it, or has people that are off sick/on holiday then it’s not being worked and needs attention.
2. Its really obvious if someone’s working on lots of different things at once (they’ve got multiple avatars on lots of stories). This might not be a problem, but is worth thinking about.
Hi Davie–
Excellent idea. I’d forgotten about seeing this a few times. I know a couple of teams that use this approach also to minimize the amount of work in process. Each team member has one photo of him or herself that can be put on one task card to indicate the one thing they are currently working on.
Thanks for mentioning this great approach.
> One way to deal with the “who’s working on what” question is to
> print out little avatars for each developer (either a picture or a
> character created with something like http://www.sp-studio.de/
> works well, or corner of post it with your initials on will do) and
> stick them onto the story that each person is working on.
One (very good team) I know attacks the same problem from the opposite angle. Instead of having a single IN PROGRESS column, they use several sub-columns – one for each team member. These sub-columns are marked with the team members’ names drawn in a funny way and again everybody is able to see who works on what.
[...] Daily Standups: en las metodologías ágiles una parte importante del proceso son las reuniones en que los miembros del equipo comentan su trabajo para decidir que hacer en la siguiente iteración. En este artículo el autor propone cambios en la forma de reportar el trabajo para que haya una mejor visión de cómo va el proyecto y que se ha hecho. [...]
I am increasingly seeing little identifying marks (stickies, avatars) on teams’ task boards and this is great for visibly showing who is doing what (so you can get some context on the stuff in progress).
Something I tried once with mixed results was to have an iteration timeline.
This was basically the ‘in-progress timeline’ – when something was ‘in-progress’ the person working on it places it on the timeline (on the date they expected it to be done) – again this is about visibility in progress but also commitment. Then we have very focused daily scrums around the timeline bit of the taskboard.
It worked well from the visibility angle, but was a little weird because some developers did not want such visible commitment! Also it can become a command and control tool in the wrong hands!
We could have tried it for longer – and I think it may have been more succesful.
Mike.
I’ve encountered similar situation when working as scrum master on project with bit too big scrum team (which we had no possibility due to external reasons to split), which caused it harder to track the progress of individual items. I found few useful practices that helped us through.
1) The blocker cards mentioned earlier. I printed a pile of stop -sign looking cards that had line where to write who or which is blocking the story. Whenever someone got into situation that he could not go on with his work on certain story he brought it up and we added a stop-sign on taskboard. After each daily scrum we went through the stop-signs and decided who will take care of that the stop sign can be removed at next stand up.
2) As the project was game development project, the cross functionality of the team was limited (we could not put graphics artist to work on programming, or audio engineer to work on graphics), why we also followed discipline specific burndown (split on programming, testing, graphics, design, and misc). When added together to big amount of active stories, it sometimes lead into situation where for example some programmer was waiting for certain graphics or design part so that he could finish the story he had been working but as for example designer could not provide it immediately due to other story he was working on, it might get forgotten by both designer and programmer for some days as both waited for other to work on it. For this the solution was that I automated my excel sheets to provide me item level burndowns for each story. Each day before the daily stand-up I went those through myself and observed if any story that had been already started (some progress was seen on burndown) had stagnated for more than a day, but still had no blocker card assigned onto it. In such a case I brought those items up for team during daily stand up and asked if there is some blocker in there or some problems that were not reported for the team as progress it in seemed to be stopped. This had remarkable effect in getting things running smoothly. It added a just a bit more work for me as a scrum master and practically no additional work for other team members.
H-P,
Those are excellent ideas. Thanks for sharing them.
Mike. I don’t understand why you’re not a fan of prioritzing storeis
within the sprint. If something unexpected occurs (central members sick
for long time for example) that the team cannot handle sometimes the team cannot deliver everything commited for.
As a customer you would be dissapoitned if the result was that you did not get your most important story delivered but instead the lesser important ones. Also if you do Scrum with setting broad targets as well as filling the
iteration with alle the stories to deliver for the iteration you will
have a your guiding priority there anyways.
In our organization we prefer to do both broad goal setting and prioritizing the stories within the iteration. But of course most of the time the Team does not overcommit and most of the time we handle all challenges thrown at us, but not always.
Hi Kim–
More or less, your comment points out exactly why I’m opposed to prioritizing stories within a sprint: Most of the time a team should finish all that they commit to, which means that the effort prioritizing them will be wasted effort. (Yes, it should be small per sprint but still unnecessary.)
Also, for teams where finishing all committed stories is NOT the norm, I find that they use this prioritization as a pre-existing excuse for not finishing what they commit to.
I like the idea that we can have as many meetings as we like in Scrum – but first let’s make the meetings we MUST have work the way they are intended to work.
So when I coach my teams in their daily scrums, I emphasise that the questions are not ‘what did you do (as a person) since yesterday’ – which invites responses such as ‘i wen to this meeting and had that conversation (which has no bearing on the stories we committed to -although might indicate distraction’. But rather they are person by person, focused on the stories (and tasks).
Actually the most practice I have coached and had most dramatic feedback from has been the tasks on a timeline (Burndown chart 2 see http://agile-blogs.com/agile-coaching/making-your-burn-down-chart-do-more/). This way it becose really focused on the tasks (and stories), and the commitment to complete a task by a certain date on the timeline (which essentially replaces the inprogress column). It also brings into sharp focus and enhances visibility of impediments and how they are having direct effect on the journey of tasks to DONE over time.
And the quiz – is awesome. I say to teams that the measure of the effectiveness of their daily scrum is…
If I can pick someone at random and they can tell me what another person on their team (again picked at random) has done, is doing and what blocks they have.
If the Scrum master has reported on his impediment list and everyone (again anyone can be picked at random) knows what is blocking the impediment list.!
If any task that has been marked as taken more time than was originally estimated now has other team members who are free (ornot) on the case trying to do what they can.
Its late and I ramble.
Mike
Hi Mike-
I’m going to throw my two bits in on this and say that, overall, story-by-story is the way to go and certainly my preference. Daily scrums going story-by-story puts the emphasis on what the team produces! It is similar to the notion of “watch the baton, not the runner” in systems/lean thinking. For each story “in progress” each team member involved in that story will say what they completed, what they will complete, and any blockers in the context of the story. What they really do if it’s working well is “get in sync.” I encourage the team to only work on a few stories at a time to minimize work in progress by pairing and swarming as appropriate. (Teams new to Scrum will always put too much in progress and usually get burned and realize that’s not they way to go.) Since there only a few stories in progress the stand-ups stay short and focused. Also, stories are prioritized in the sprint by default in the order they were the product backlog, but I let the team decide how to attack the stories as a team and they can use that priority as they see fit. Since I don’t force work order and utilize commitment-based planning I don’t get the “it was lowest priority” excuse. However, most teams will try to maximize their completed story points (velocity) in some fashion depending on risk and size of the stories (frankly it’s the smart thing to do). We do both the traditional task burndown and a “story point burnup” on the same chart to assess both capacity remaining and velocity accumulation during the sprint.
[...] If you are looking for more analysis of person-by-person versus story-by-story standups, here are Mike Cohn’s expert thoughts on the matter: Should the Daily Standup be Person-by-Person or Story-by-Story? [...]