Why Insist on Standups and IPMs

Product Management
Merziyah Poonawala
Senior Project Manager

If you’ve been around techies, the terms “standup” and “planning meeting” might be familiar to you. For the uninitiated, standups and planning meetings are a standard activity for every agile team. These meetings facilitate the core beauty of agile development, namely customer collaboration and the ability to respond to change. Regular check-ins help to keep the team constantly aligned, and enable the team to quickly adjust for changes. Needless to say, as an agile development shop, Def Method strongly recommends these for every project. If you are unsure of how to go about incorporating these agile practices, read below and reach out to us on how we can help you become more agile.


The What

Standups are short (general rule is less than fifteen minutes) daily meetings where all attendees stand for the duration of the meeting.

The When and the Where

Same place, same time, every work day. Although many people like taking standups in the morning, standups are not meant to be a day-starter, so pick a time that works best for your team. For colocated teams pick an open area where the team can huddle. For remote teams set up an online session that everyone can dial into. We’ve successfully used Google Hangouts with video enabled to allow face-to-face interactions. The best is to keep the “when” and the “where” consistent.

The Who

Anyone impacted by the day-to-day progress and deliverables of your team. This of course includes the engineers, the product manager (PM), the designer and a decision maker from the client’s team. Other team members who might be invited are a sales or marketing team representative or your customer engagement manager.

The How

All attendees take this meeting standing, which ensures no one gets too comfortable to engage in an elongated discussion. If a conversation requires more than a couple of minutes it should be flagged for a separate meeting.

The standup focuses on three questions:

  • what you worked on yesterday
  • what you are working on today
  • any “blockers” that are preventing you from making progress

Responses should be concise and focused on completion of the task at hand. Questions may be raised and responded to, but the standup is not meant for problem solving; take longer conversations offline and discuss separately with the relevant team members.

The Why

At Def Method, we invite all of our clients to be part of their project’s standup. The standup allows the team to check in and for our clients to track daily progress on the product. Having a decision maker from the client’s team enables quick resolution to questions the team may have about the product and ensures the team stays focused on the product goals. This daily meeting helps to identify and create action items to resolve any “blockers” or obstacles that a team member might be facing in completing their task. The regular touch point with the team has the added benefit of developing team cohesion.

For clients, the daily standup enables you to follow the daily progress on your product, recognize the challenges the team is facing, and get a sense of the pace of development. While the technical details of issues are not necessary for you to understand, you will be informed of what might hold up progress and be able to make decisions around them. You will be able to clarify questions around business decisions and ensure developers are making sound choices in light of the product’s goals.

IPM or iteration planning meeting, aka sprint planning:

The What

A meeting at the start of each development sprint where the team cohesively selects the most important user stories from the backlog and decides what they can commit to delivering in the upcoming iteration. The meeting establishes the goals for the sprint and what deliverables are expected at the end of the sprint. It also clarifies the team’s current and long term goals, answers any open questions, and reassesses the team’s current priorities.

The When and the Where

This meeting happens at the start of each sprint. A sprint is a set period of time, usually one to two weeks. Each project team decides how long their sprint should last. For short term projects we go with one week sprints so as to allows quicker review and feedback cycles.

We encourage the IPM to be in-person. Even if your developers are remote, have your product manager with you during the IPM.

The Who

IPMs are attended by the client, the engineers and the PM.

The How

During the IPM, the PM and engineers start by selecting the next available stories from the backlog of user stories, which is kept constantly prioritized by a joint effort between the PM and the client. For each selected user story, the functional and non-functional requirements are reviewed, the acceptance criteria clarified, and specific development tasks listed out. Testing criteria may also be noted. The team will also discuss any possible risk factors associated with the story and how that might be mitigated. Once all the requirements are clarified, the engineers “point” or estimate each story on a numeric scales (1,2, 3 or fibonacci), usually using a complexity and scope evaluation rather than by time factor. Anything estimated as large should be looked at to see if it can be broken down into smaller user stories. Often, teams will setup a “Grooming” meeting ahead of the IPM to ensure all the stories are detailed, prioritized, and ready for the team during the IPM.

Once all the stories are pointed, the team reviews their “velocity”. This is the number of story points the team is expected to complete during the sprint, based on the results of previous sprints. Using this velocity, the team commits to a set of user stories they will complete within the sprint.

IPM meetings may also be prepended by a demo of the work completed during the previous iteration where the client provides feedback, which, along with any identified bugs, are incorporated into the next sprint.

The Why

IPMs help keep business and engineering teams aligned, provide information on the product’s status and creates a structure to collect regular feedback. Primarily, the IPM helps re-establish the goals of the project for the engineers on an ongoing basis. Business environments are constantly in flux and regular IPMs allow any team member to raise changes in priorities as the market shifts. This is where agile shines. The client is able to keep the team abreast of business needs and results of ongoing user testing and can discuss a pivot of priorities at any time during the development process. You, as the client are not “trapped” by a multi-month plan with no leeway to make adjustments.

Every IPM also provides the client with a status of progress and is an opportunity to view your project burndown (how your development is progressing against its expected delivery date) and work with a realistic time frame for launch. This allows you to track how that final date adjusts as you add new features or remove features from the backlog. What is important is that you are kept informed and that there are no surprises.

The IPM allows the team to receive regular feedback - both on the product as it takes form, as well as the processes being employed. Supplementing an IPM with a product demo of the work done thus far allows the client to make necessary adjustments and guide work along the way as opposed to coming back with changes that would require significant re-work once the final product has been delivered.

And there’s the What, Where, When, How and Why of standups and IPMs. The exact nature of these meetings varies by project and team. To learn more, talk to any one of the Def Method team members— we love sharing our agile experiments and experiences!

Lastly, don’t forget to supplement your hard work with a regular retrospective to learn what is and what is not working for the team. For an example of how to conduct a retrospective, see our description of the Sailboat exercise.

Read Next Article -->