One question to find out if your stand-up meeting is useful


The original objective of the scrum stand-up meeting is to assure that all team members make a commitment towards their peers. That means is that you will do as you say.

The idea that by saying what you will do in front of your peers is that you will feel more social pressure to actually do it.

The idea of standing up is that the meeting stays within 15 minutes. The assumption is that we don’t like to stand for much longer.

The scrum stand-up meeting is not a status update meeting.

There are three questions everyone is supposed to answer:

  1. What did I accomplish yesterday?
  2. What will I do today?
  3. What obstacles are impeding my progress?

This will create more transparency with what’s happening in the team, right? This is not necessarily true.

Add the following question after everyone has had their turn and find out if your stand-up meeting was a waste of time. Aks several team members.

What were the answers of team member X or Y to the three questions?

When several people can’t answer this question your stand-up meeting was a waste of time.

What can you do about this? Here are some suggestions to make it more effective:

  1. Focus on collaboration.
    1. Who needs to work or talk to who? Make sure they both agree to do so.
    2. When using a scrum or kanban board make sure that team members actually discuss stuff that is on the board. Stay sharp that people don’t wonder off doing other stuff. Is your board representing current reality? If not, inspect and adapt.
  2. Adapt the meeting structure (and length) to support what the team needs.
    1. Allow asking different questions or having some discussion.
    2. Allow for a different timing when needed to support alignment, collaboration and information sharing.
  3. Focus on agreements and decisions.
    1. Make sure the team aligns on goals and priorities and make agreements.
    2. Make sure the team calls on missed agreements.
    3. Make sure existing agreements can be re-negotiated.
  4. When a team is strong on collaboration, you may even make this meeting optional.
    1. Facilitate the meeting every day anyway.
    2. Make it everyone’s personal responsibility to decide to join or skip.
    3. All decisions made during the meeting are binding unless re-negotiated and agreed upon with those present.
  5. If you want to stick to the original scrum questions find out why people can’t answer the suggested additional question. You may have a team culture issue here.
    1. Did they not pay attention (this time)?
    2. Is the information provided to them not interesting enough? If so, why?
    3. Is there too much or too little information to make it useful?

Happy stand-up next meeting!

The simplest and most effective Definition of Done


The Definition of Done describes the criteria when a user story finished. It regularly is an intensive lists of criteria. An example could be:
  1. All code is checked in;
  2. All code has written tests;
  3. All tests are passing;
  4. Code review conducted and passed;
  5. Functional documentation updated, reviewed and approved;
  6. Design documentation updated, reviewed and approved;
  7. User documentation updated, reviewed and approved;
  8. QA check passed;
  9. etc.

I have not seen this work very well. Teams claim they are done, but the story is “done” somewhere in a staged system. Some work is left to deploy it to production. 

This type of list starts small and simple and grows over time. When the team misses something a new line is added.

When that line is not applicable for all user stories the team starts cheating. They need to make exceptions in order to ever finish a user story.

The efford needed to move user stories to production may vary and becomes part of the next iteration(s). Consequently, less time is available to build new features and the velocity becomes unpredictable.

Here is a simple and very effective Definition of Done that works much better. Are you ready for it?

The user story is deployed to production and can be used by the end-user.

Rockstar developers consider stuff like: all code is checked in; all tests are passing; etc. part of their de facto standard. Neither discussion nor a special list is needed for this. Specific attention points can be added to the acceptance criteria.

Use the above definition and you will be fine.