Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Another team in my company start to document their stand-up meetings, but I believe it is a waste of time. As far as I know, stand-up meetings are for communication not for status reporting (please, correct me if I am wrong)

So, Should we document stand-up meetings?

share|improve this question
2  
Ask the other team if they gain anything significant from that documentation. Unless they can show that they do, let them do it, but ignore it. –  Joachim Sauer May 29 '12 at 11:43
19  
Slippery slope. First person needs to sit to write down the note(s). Next thing you know, your "scrums" are 1hr long. I'VE SEEN IT HAPPEN! HEED MY WARNINGS! –  Steve Evers May 29 '12 at 12:54
4  
If you're doing something significant enough to need documentation in a stand-up meeting you're probably doing either the meeting or documentation wrong. –  Ben Brocka May 29 '12 at 13:08
1  
@BenBrocka You read my mind. The urge to document stand-ups probably means that you're using the stand-up meeting for more than it should be used for. –  Eric King May 29 '12 at 14:52
    
Sidenote; if you find yourself having too long of "stand up" meetings, see this Q: workplace.stackexchange.com/q/465/42 –  Ben Brocka May 29 '12 at 15:04

10 Answers 10

up vote 12 down vote accepted

One of the benefits of Agile is that each team can determine what works best for them, and go with it.

However: should you take notes? No; in my experience, the minute a team decides to start backtracking on some of the core principles such as:

  • individuals and interactions over processes and tools (documented scrums that begin to be non-scrum-like) AND
  • working software over comprehensive documentation (scrum minutes one day, who knows what would be next)

then that team will begin to move away from Agile and toward a more documentation-heavy and low-velocity approach to work.

In Martin Fowler's "It's Not Just Standing Up", there's nary a mention of note-taking or documenting the "minutes" of a stand-up meeting. All you should take away from that stand-up meeting are GIFTS:

  • To help start the day well
  • To support improvement
  • To reinforce focus on the right things
  • To reinforce the sense of team
  • To communicate what is going on

As a mnemonic device, think of GIFTS: Good Start, Improvement, Focus, Team, Status

However, if someone has a blocker that you need to help him or her work through and you take a note on what they are saying, that's totally different. -- knock yourself out with that.

As a point of reference, I'm a Product Owner and am mentoring the ScrumMaster right now in my company, and of all the Agile meetings we have (scrum, sprint planning, sprint review, sprint retrospective), the only one we take official minutes of is the retrospective, because that gives the team something concrete to work toward and refer to in the next sprint (and those "minutes" are a couple sets of short bullet points).

share|improve this answer

Your scrum should be:

  • What I've worked on
  • What I'm working on next
  • Any blockers

That's it. Quick and to the point. 5-10 mins max. Absolutely no need to document, but if anyone needs to jot something down to action, that shouldn't be an issue.

share|improve this answer
3  
Well, the one "document" is the planning board to document current state. –  Steven Burnap May 29 '12 at 16:12

In the last company I worked for, we used to only document grand decisions made during stand-up meetings.

As you said, stand-up meetings are for communication inside a small group of people, and it does only concern that specific group of people... anyway... sometimes... someone says something interesting that may be important and eventually can influence the way the project is made (it was often warnings about tricky bugs to take care of, or technical points very important to know). That's why we started to document ONLY the 'important for a better future' points.

I think, document stand-up meetings is smart if you are absolutely sure about the importance of the content and only if you can say it will help your team sometime in a near or distant future.

share|improve this answer

Treat stand-up as a casual meeting – without the expectation that statements are formal, final, etc. which will make people less likely to raise topics they're not yet comfortable with – but simply have the understanding that anything important should have the discussion continue somewhere else even if it's just a simple email to the team. Besides helping keep standup from turning into a full project meeting this also avoids excluding anyone who couldn't make it to a particular standup.

share|improve this answer

In my experience, stand-ups are a great way for getting a "heartbeat" of where the team is on the project. The ones I attend are a few minutes each, which aren't really long enough to merit documenting, but they great for getting a sense where things are along the process, and for giving me a heads-up on anything that could impact me in the immediate term.

If something particularly profound of noteworthy comes up from a stand-up meeting you should document just that and broadcast it out separately, but I wouldn't get into the habit of documenting every meeting every day.

share|improve this answer

In my current company, we have 2 Scrum teams with separate standups and document them by sending a summary email at the end of each standup. It works pretty well, making important information immediately known to all the members of the other team. We don't particularly keep a history of the mails for archive purposes though.

So my advice would be :

  • For a single team, documenting stand ups may not be worth the time spent. The Scrum Master can just relay alerts or important information orally to whom he sees fit afterwards.

  • For multiple teams whose work is closely related, documenting stand ups is a way to broadcast potentially game-changing information immediately after the meeting without waiting for a Scrum of Scrums to happen.

share|improve this answer

I see no problem marching away from such a meeting and firing off an email to the group as a reminder/clarifier of a significant decision that were made or actions that arose. After all, you don't want to risk forgetting or letting time fade the memory of what was discussed.

But as for formally documenting the meeting, like you might do for a more traditional meeting... well, it seems counter-intuitive. Such meetings are supposed to be lean and agile, so bogging them down with too much 'process' seems counter-productive.

share|improve this answer

There isn't (there almost can't be) an absolute answer to that - its very much an it depends...

Pragmatically, if you're doing "what did I do, what am I going to do, here are my issues" then there might well be merit, for some (those notionally in charge), in recording that so that you can check against it in the next meeting (although "working on" should also be apparent by other means) - but not particularly beyond that i.e. its a piece of information that should cease to have value once the next meeting has finished.

Additionally if there are matters/meetings arising from the standup then there is potentially value in recording those to keep track of whether the followups actually took place (although again I'm sure I'll be told that mostly this should become apparent by other means).

Formal minutes though? I'd've thought those contrary to the spirit of the thing.

share|improve this answer
    
Downvotes without explanation are not paricularly helpful )-: –  Murph May 30 '12 at 13:03

Does it add value? Do people later look at the documentation of the meetings? If not, then it just a waste of time. And I seriously doubt that they are. Writing a document that nobody reads is a waste of time.

At some point in time we did actually document and archive status changes from our daily scrum, i.e. who worked on which task, who had performed a peer review, etc. This was done only because someone felt it necessary in order to be compliant with the requirement of traceability from system requirement to code because we were developing software for medical devices.

Later we managed to convince management that this was not really the case, and the practice has been abandoned to much joy for those responsible for this documentation.

share|improve this answer

Yes.

Are you making decisions about (a) who is responsible for a work item and/or (b) the importance of a work item relative to other items?

If you are, write these decisions down. Otherwise you will rehash them, and decisions just like them, endlessly.

If you aren't, don't hold the meetings.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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