The Scrum Guide states the Daily Scrum is an event which the Development Team plans work for the next 24 hours.  Far too often teams are working on a mixture of items that are not related to each other or are assigned to team members which locks in boundaries between people.  The day-to-day microplanning envisioned by the authors of the Scrum Guide slip through the team’s fingers and land directly on sharing status especially when driven by the classic three questions: (more…)

Every Day?


Daily Scrums or stand-ups are a fixture of teams, agile or not, whether they are fulfilling goal identified in the Scrum Guide or not. The Scrum Guide identifies the Daily Scrum (often colloquially known as a stand-up) as one the key events in Scrum.  The purpose of the event is to plan work for the next 24 hours. The meeting are short, approximately 15 minutes, therefore don’t feel like a huge investment of time and money. Wrong!  An agile coaching colleague, Anthony Mersino points out that the Daily Scrum has a cost.  His estimate of $60,000 – 110,000 annually for a typical Scrum team is probably conservative if you factor in the impact of gathering time and getting coffee afterward. Done well there is an offset to the cost.  The value of the meeting comes from micro-planning and collaboration that occurs during the stand-up. The issue is that Daily Scrums or stand-ups don’t always make sense, at least the daily part. Don’t spend the money for a daily stand-up meeting when: (more…)

Preparing for a Daily Stand Up

Preparing for a Daily Stand Up

The daily stand-up meeting is the easiest Agile practice to adopt and the easiest to get wrong.  In order to get it right, we need to understand the basic process and the most common variants. These include interacting with task lists/boards and distributed team members. The basic process is blindingly simple.

  • The team gathers on a daily basis.
  • Each team member answers three basic questions:
    • What tasks did I complete since the last meeting;
    • What tasks do I intend to complete before the next meeting, and
    • What are the issues blocking my progress?
  • The meeting ends, team members return to work OR discuss other items.


Listen to the Software Process and Measurement Cast 285. SPaMCAST 285 features a compilation of frequently asked questions of a consulting kind.  Working as a traveling consultant, podcaster and blogger provides me with a fabulous mix of experiences. Meeting new people and getting to participate in a wide range of real life experiences is mind expanding and invigorating. Many of the questions that I have been asked during a client engagement, on the blog or in response to a podcast have similar themes. Since most of the answers were provided in one-on-one interactions I have compiled a few of the questions to share. If these questions spark more questions I promise to circle back and add to the FAQ list!

The SPaMCAST 285 also features Kim Pries’s column, The Software Sensei. In this edition, Kim tackles the concept of failure mode and effects.

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature an interview with Brian Wernham author or Agile Project Management for Government. Combining Agile and government used in the same phrase does not have to be an oxymoron.

Upcoming Events


I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE…. Email me at or call 440.668.5717 for the code.

ITMPI Webinar!

On June 3 I will be presenting the webinar titled “Rescuing a Troubled Project With Agile.” The webinar will demonstrate how Agile can be used to rescue troubled projects.  Your will learn how to recognize that a project is in trouble and how the discipline, focus, and transparency of Agile can promote recovery. Register now!

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.


Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.



Your Scrum events might be slightly less well attended!

Your Scrum events might be slightly less well attended!

The list of identified events in the Scrum framework, like the number of roles, is highly constrained. Scrum walks the line between identifying a set of events that each follow a typical pattern and prescribing specific activities and tasks.  As a framework, Scrum leaves the control of specific behaviors to the team. Therefore each team has a customized approach to how they implement the events based on organizational culture and need. The events identified in the framework include:

  1. The Sprint: which is the time box for developing potentially implementable functionality.  The sprint generally ranges from 2 – 4 weeks, with the 2 week increment being the most common I see in the industry.  Once your team agrees on the sprint duration for a particular project, it generally does not change.  The standard duration of the sprint is called cadency. Developing a consistent cadence helps the team become predictable.
  2. Sprint Planning: a meeting for the team to plan the work they will commit to during the sprint.  Sprint planning is a two-step process beginning when the product owner identifies the units of work they want included in the sprint using the prioritized backlog and input from the team for guidance.  After the product owner identifies the work he or she wants in the sprint, the development team (I recommend that the whole team participates) estimates the work based on their velocity (how much work they typically get done in a sprint) and the activities needed to complete the work (completion must meet the teams overall definition of done). The team will either increase or decrease the number of work items based on what they can complete.  What the team WILL NEVER do is to change the definition of what done. The planning activity is complete when the team can commit to completing the work they can do during the sprint.
  3. The Daily Scrum: the daily planning session that generally begins the team’s day.  The daily meeting provides the team with a mechanism to plan the day and to ensure that issues blocking work do not fester. Try to keep the scrum meeting at or near the beginning of the day so that team can use it as tool jump start their day.  Team composition and time zone constraints will dictate when the meeting happens.
  4. The Sprint Review: the meeting at the end of a sprint for the product owner and stakeholders to interact with the functionality and provide feedback and acceptance.  The sprint review provides a platform to gather feedback from a broader constituency than the team itself. The whole core team should be interacting on a daily basis; therefore the review should be leveraged to include a wider range of stakeholders.  The product owner should drive the guest list with advice from the entire team.
  5. The Sprint Retrospective: a meeting for the team to review their performance and identify opportunities for improvement. The team should find at least one process improvement that they can make and then commit to making that change.  The change the team commits to should be captured as a unit of work and be incorporated into the next sprint backlog so that it gets done.  Process improvement is the obligation of the WHOLE team, not just the development team.

The five events identified in Scrum are sometimes explained as four meetings and the sprint, which is an intrinsic part of Agile techniques.  All five are important features that interact providing self-reinforcing discipline and feedback.  I usually worry less about how a team is accomplishing the events, rather I make sure they doing something that meets the intent of the events and are in line with the Agile values and principles.

The stand-up meeting is all about planning!

The stand-up meeting is all about planning!

One of the most ubiquitous features of an Agile implementation is the daily meeting. The daily meeting is known under many names, such as the “stand-up” meeting and the daily scrum. I am often asked if the daily meeting is meant to be a status meeting, a planning meeting or some combination? In its simplest form the daily meeting gathers the core team and answers three basic questions.

  • What did I accomplish yesterday (or what did I do yesterday)?
  • What tasks am I going to complete today (or what am I going to do today)?
  • What is blocking my progress?

The meeting is generally severely time boxed (approximately 15 minutes).

There is a debate about whether the daily meeting is a status meeting or a planning meeting. If we take the point of view of  a classic project manager in a waterfall project, where a project’s tasks are planned and metered out to the project team in advance, the daily meeting is primarily a status meeting. Planning is done upfront and then tailored by the project manager. From this point of view the daily meeting would be a status meeting. Agile projects take a different tact.  Planning is done in layers. Release plans feed iteration/sprint plans, which in turn are used to plan each day’s activities.  In Agile, planning is a daily activity based on an intimate knowledge of where you are right now.  In an Agile project the daily meeting is a planning meeting.

The three questions outlined above provide the team with the basis for the day’s plan. The first question, what was accomplished, makes sure the team understands which tasks are complete or not.  When each team member tells his or her peers what task they are going take today, they can react to the needs of the team are based on current information.  Knowing what the blockages are provides the Scrum Master with additional tasks to expedite into their day, specifically; anything blocking progress needs to be the top priority.

The case is clear, in Agile, the daily meeting is a planning meeting. While it provides the team with a crisp understanding of the progress the team has made, it primarily provides a platform for team members to take on the next task based on that progress.  The team plans and then re-plans daily based on feedback.


Stand-up or Scrum meetings by definition must be compact and concise in order to coordinate and plan the team’s daily activities. The rule for stand-up meetings is 15 minutes or less. Crisp meeting etiquette and a few rules are mandatory for stand-ups to be effective. The short list of rules for every stand-up meeting is: show up on time, stand and minimize distractions.

Showing up to the stand-up meeting on time sends a message to your fellow teammates that you take the meeting and their updates seriously. Getting to the meeting late and then rehashing topics that have been discussed reduces effectiveness and efficiency. Holding the meeting first thing every day makes it easier to avoid scheduling conflicts, however this can be very difficult for everyone on a geographically distributed team. Regardless of when the meeting is held, everyone on the team needs to commit to being on time.

The goal of having people stand during the stand-up meeting is many-fold. First, by standing, we allow energy to freely flow throughout our bodies, which improves thought and communication. And while that might sound a bit too zen-like, research has shown that standing helps you stay more alert and forces you to take a more active role. Secondly, and perhaps more pragmatically, standing is a little uncomfortable, which helps everyone involved to focus.  When the participants are sitting they tend to get overly comfortable and wander off topic. Sometimes I remove the chairs from the office I am using for the daily stand-up. Note: it is very difficult to hold a stand-up while driving a car.

Distractions come in many flavors, including ringing cell phones, laptops, random passersby, rock bands in the next office and participants updating project management tools during the meeting, just to name a few. While it is important to hold the meeting in the same place every day, if the location is noisy or crowded on one day out of five, move the meeting.  If your stand-up meeting location has a door then close it, and if does not have a door, take the responsibility to find a quiet, low-traffic place to hold the meeting.

The effectiveness and efficiency of the daily stand-up meeting is greatly improved by embracing some simple meeting etiquette.  Simply put – be on time, stand up (even if you are on the phone) and turn off anything that could distract you from the conversation.  Most people can stand and avoid responding to email for 15 minutes a day!