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?
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:
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).
Your scrum should be:
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.
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.
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.
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.
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.
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.
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.
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.
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.
