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.

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. This way it because 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

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.

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.

Those are excellent ideas. Thanks for sharing them.

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.

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.

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.