10

I know that Scrum rules in daily standups say that team should only talk about what they did yesterday, what they're doing today, and anything blocking them. Nothing else. But the problem is, sometimes developers spend their day doing work irrelevant to their tasks, and then talk about it in the standup. It's what they did yesterday!

In my experience, I found that it's more effective to talk about tasks on the board, to keep the standup focused, and to keep everyone's focus on their tasks, to review their estimations & track their records daily.

Is it valid to limit the discussion to the tasks on the board?

  • 1
    That developers spend whole days not working on their tasks could be a problem that would be invisible if not mentioned? – RemcoGerlich Nov 23 '16 at 15:13
  • Everyone talks 30 seconds to say what they did before. How much more focused do you want it? You do not review estimations. You track tasks when you pass them to the next guy (reviewer or tester). – gnasher729 Nov 23 '16 at 15:36
5

As per the Scrum Guide content on daily standups, the three questions for discussion are:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

All of the questions focus around the Sprint Goal, not the tasks that are on the board. Again, per the Scrum Guide, the Sprint Goal is created in Sprint Planning and it defines "an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment".

Everything that your development team does should, ideally, be helping the team progress toward the Sprint Goal. These may be unplanned activities that aren't on the board that had to be done, or they could be things at a lower level that may have been considered and estimated, but at a lower level than an item on the board.

I would say let your team talk about everything that they did yesterday. If they are talking about things that don't help the team reach the Sprint Goal, then someone should bring this up, especially if there were other things that they could have done that did move the team closer to completing the Sprint Goal.

One exception may be if an individual is supporting multiple Scrum teams. In the meeting, they probably shouldn't talk about everything they did yesterday, but what they did in support of the team that is currently having the standup.

The Sprint Retrospective is a great time to talk about this issue with the team. There are plenty of questions to consider:

  • Is the team underworked on items related to the Sprint Goal?
  • Is there too much unplanned work?
  • Where is the unplanned work coming from and who is authorizing it?
  • Why are people working on things not on the board?
  • Should we be showing more details on the board to tie the things you do to items on the board more easily?
| improve this answer | |
  • 2
    the trouble with "Sprint Goal" is its too vague and wishywashy. in practice Sprint Goal == complete the tasks on the board. if what you worked on isnt on there either it should be or you shouldn't be working on it – Ewan Nov 23 '16 at 16:11
  • 1
    @Ewan A customer calls and tells us that the live software crashed and we have a log and a bug report. It's important to take the time to triage that report immediately, even if it's not on the board right now. It may be brought into scope or it may be put onto the backlog, but it's something I did yesterday and could be why I couldn't help Bob with his problem until after lunch. I shouldn't do that task blindly, but no one is probably going to put it on the board unless it is pulled into this Sprint. I can think of other examples, too. – Thomas Owens Nov 23 '16 at 16:25
  • 1
    you should add a ticket "triage live bug" to the board and mark it done. Then at the end of the sprint you can say for sure. 'this sprint we spent X hours looking at user errors. That is why we are late. we need to train the helpdesk better' Otherwise you get nothing done that sprint and the PM just has hearsay excuses from the team 'oh there were loads of bugs to look at this week! shrug' – Ewan Nov 23 '16 at 16:37
  • 1
    @Ewan I think that is incredibly unnecessary. I don't want to spend my day writing tickets. A process needs to let me get my job done, and taking 90 minutes to triage instead of 95 minutes to triage and then put in a ticket that said I triaged a ticket is silly. Especially if you have to triage multiple tickets. You don't need tickets to discuss things at the retrospective. If you're using electronic tools, you can find tickets modified by the team in the Sprint to see if there were a lot of things to triage - no hearsay there. – Thomas Owens Nov 23 '16 at 16:46
  • 1
    the level of reporting if up to your scrummaster/pm/company. you could just write up one "trigaing bugs" ticket to cover all your work for the day. But the important thing is that you RECORD IT AS PART OF THE SPRINT. dont assume that its just factored in by some other metric – Ewan Nov 23 '16 at 16:52
0

No, you should talk about what you did yesterday.

If its not on the board you need to do one of the following:

  • put it on the board,
  • stop doing it
  • or change teams.

The most common one, say for unplanned emergency work, is to write up a card and stick it on the board. This ensures that at the end of the sprint you can measure velocity and explain why sprint goals were not achieved.

A team member working on stuff which is not in the sprint is in my view one of the primary reasons for agile adoptions failing. Most commonly this is a developer diverted to fix live issues on another project.

Another annoying thing in sprints is "PM talking about meetings for other projects". In my view the PM is not part of the scrum team, they fill the 'Product Owner' Scrum role and thus there to answer questions, not report progress.

| improve this answer | |
  • 3
    There is such a thing as unplanned work - work that needs to be done to unblock someone or do other tasks that are on the board, but it is not on the board. Often, it may be faster to just do it then to put it on the board. It's up to the team to discuss how to handle that. My current team has rules - anything that is deployed to a production or QA environment or tasks that take 2 hours go on the board. There are still sometimes shorter tasks that need to happen that are talked about but don't make the board because it doesn't fit the criteria. – Thomas Owens Nov 23 '16 at 15:55
  • @Ewan, can you please expand on that? Who handles fixing live bugs, if it's not in the Sprint? How can Project Owner at the same time be Project Manager? (I mean which is he, or is he juggling both roles) – Dennis Nov 23 '16 at 15:57
  • edited for clarity – Ewan Nov 23 '16 at 16:04
  • @Dennis: Project Manager isn't a Scrum role. – RemcoGerlich Nov 23 '16 at 16:21
  • @Ewan, thanks. This is not essential to the answer, but I am curious -- the "PM talking about meetings for other projects", how does this work? Do PMs come into a meeting about project X, but talk about Y? I have a hard time visualizing this. How/why is this possible? Do you mean they come in and essentially start gossiping or going off-topic or is there a deeper reason for them to talk about non-immediate meeting-specific goals/needs? I'd say "hey nice to be hear this but I am not a part of project Y ... no knowledge/experience there, can we get back to X?" – Dennis Nov 28 '16 at 16:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.