Skip to main content

Daily scrum misconception, scrum meeting objectives and different stages of meeting

I talk a lot about scrum. Many times when I speak I hear people saying that they are also doing scrum and they have daily scrum status updates. No other ceremony is so blatantly misused. It’s a misconception that scrum is only about stand ups. I have seen a project manager doing a scrum update with a big team, the status update itself took 1 hour, and the information passed was so huge that nobody remembers anything. By the time the last person updated his “status” the first person would be sleeping. Starting a daily meeting and asking for status update does not falls under Scrum. Many are thinking about “what are the scrum meetings rules” rather than thinking about “why do we need this meeting”. I prefer calling this as Scrum Planning meeting.

This is the planning meeting for the day. I can add the following objectives to the meeting
  • To see if the team is on the correct path, will they complete the committed task if not what changes should be made to accomplish the objective.
  •  Discuss and take actions on the risks faced by the team in meeting the commitments.
Apart from this status update mentality there are some dysfunctions also which should be avoided.

  1. Coming to meeting un-prepared - I have seen many occasions when team members come to meeting without any preparation. They are even unaware of the tasks which they are supposed to work on. 
  2. Big team - Having a meeting with teams bigger than 8-10 people is not effective. The complexity of communication will be huge & time consuming. There will be a high risk of meeting being derailed
  3. Status updates mentality - In many meeting team updates the status of work, there will not be any information about the task to be taken next. They end up updating this information to Scrum Master, Product Owner or other managers if they are present  
  4. The manager Product Owners Many managers are transitioned as Product Owners. They find this meeting as a forum for status update. They go around each one and ask the updates.

  
Even though daily scrum is time-boxed for 15 minutes, there are some pre & post actions which every team should consider.

Stages of a Scrum meeting

Pre – Planning
  • Before the Scrum meeting at least 15 minutes should be spend updating the task boards and other metrics if any. 
  • If any doubt regarding the types of tasks to be pulled then it should be cleared before the actual meeting.
  • If all the committed tasks are finished then team should plan to work on the next item from backlog. They can even do some research work on the items in the product backlog.  
Actual Scrum planning meeting
This is the actual scrum planning meeting
Follow the rules @ http://thetechjungle.blogspot.com/2012/03/daily-scrum-meeting-rules.html

Post Planning actions.
During scrum team might bring something of importance to notice which needs further action/discussions. All such meetings and follow-ups should be taken as the post scrum meeting actions.
Labels:

Comments

Post a Comment

Popular posts from this blog

PDCA & SCRUM (or Agile); Why is it important?

The PDCA (Plan DO Check Act) cycle was made popular by Dr. W. Edwards Deming. This is a scientific cyclic process which can be used to improve the process (or product). This is cyclic in nature and usually time boxed. Plan  This is the first stage of the process. During this step the team discusses the objectives, the process and the clear conditions of exit (conditions of acceptance). This stage sets the measurable and achievable goals for the team. DO Team works together to achieve the objective set in the planning phase. Team works with the set of agreed process. Check Once the implantation is done team regroups and verifies the output and compares it to the agreed conditions of acceptance decided during the planning phase. The deviation, if any, is noted down. ACT If any deviation in planned tasks is observed during the Check stage, a root cause analysis is conducted. Team brainstorms and identifies the changes required to prevent such deviations in future. Team also
Post a Comment
Read more

Why is potentially shippable product quality important

Agile teams work in iterations. During this period, they are supposed to work on product increments which can be “delivered” at the end of iteration. But how you know that the correct product was delivered? Many teams have different kinds of acceptance criteria and Definition of Done (DoD). But in many cases, this “done” is not the real “done” there might be some testing pending, some integration or review pending or anything else which prevents the actual use of the product increment. Many of these teams will need additional iterations to finish hardening their products. Many teams will implement different types of “gates” or approval steps to move to next stage. The free flow of product will be interrupted. They might end up doing mini waterfall within their agile process. Many don’t even realize this. This results in poor quality and requires additional effort to “harden” the product. Potentially Shippable Product increment The acceptance criteria and DoD should be modified
Post a Comment
Read more

Product Backlog: Should you write everything in user story format?

I like user stories a lot. They help everyone talk the same language and results in a better product. User story alone does not constitute product requirement. User story is supposed to be a place holder for discussion which should happen between the team, Product Owner and the customer. This discussion result in a common understanding which along with the user story content is the product requirement. This format captures the essence of requirement without confusing the readers User Story is only one of the many different ways in which requirements can be represented. This is not mandatory in any Agile “process”. But many have made this mandatory. I have seen many spending countless hours trying to write the requirements in user story format when they could have easily written that in simple one-line sentence in few minutes.   I have seen team members refusing to even discuss the requirement until product owner rewrote the requirement in user story format. Once I
Post a Comment
Read more