Why Insist on Standups and IPMs
by Merziyah Poonawala, Senior Product Manager
Standups and Iteration Planning Meetings (IPMs) are standard activities for every agile team, but on some occasions we will get push back from client teams who challenge us on why these meetings are important. We know these meetings are essential to realize the core beauty of Agile development through collaboration and iteration. We love to help organizations advocate for and get the most out of these touch points. Read below to learn more about implementing these agile practices and reach out to us if you think we can help your team improve their Agile processes.
Standups
The What
Standups are short (general rule: 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 workday. 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 and Zoom with video enabled to allow face-to-face interactions. We recommend making “video on” the norm. We also recommend against Slack standups, as these don’t allow for dialogue and inquiry to flow as naturally. 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 includes the core team, typically engineers, the product manager (PM), the designer, QA if applicable, and a decision-maker from the client’s team. Folks outside of the core team can be included as well. It is up to the team to decide who to include and how to include them and this can change during the course of a project. The team should self-organize the running of this meeting. A standup “captain” can be a rotating role, giving each team member the chance to facilitate the meeting.
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 conversation. It can be helpful to have a “time cop” assigned to put pins in conversations that start getting too long and ensure that follow ups conversations are scheduled as needed.
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
- any decisions you made that the group needs to be informed of
Responses should be concise and focused on the 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 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 touchpoint 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.
Iteration Planning Meeting, also known as Sprint Planning:
The What
The IPM is a meeting at the start of each development iteration where the team reviews the stories that the product manager has prioritized for the iteration in conjunction with stakeholders. The meeting establishes the goals for the iteration and scope likely to be completed based on historic velocity of the team. Each ticket in the backlog is discussed to ensure a shared understanding, and the engineers are invited to estimate the complexity of each story in the backlog to help ensure that the iteration scope is feasible.
The When and the Where
This meeting happens at the start of each iteration. The team decides on iteration length, typically 1 or 2 weeks. For short term projects we recommend one week iterations to allow quicker review and feedback cycles. We encourage the IPM to be in-person if possible.
The Who
IPMs are attended by the client, the engineers, the designer, and the product manager.
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 discussed, and specific development tasks listed out. Testing criteria may also be noted. The team also discusses 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 scale (1,2, 3 or fibonacci), usually using a complexity evaluation rather than a time factor. Anything with a large estimate is examined with an eye towards breaking it into smaller stories while still adhering to INVEST guidelines. Often, teams will set up a “Grooming” meeting ahead of the IPM to ensure all the stories are detailed, prioritized, and ready for the team to discuss during the IPM.
Once all the stories in the iteration are pointed, the team compares the total points to their expected velocity, the number of story points they have completed on average over the last few (2–3) iterations. This velocity represents the number of story points the team is expected to complete during the iteration, based on the results of previous iterations. The team adjusts the scope of the iteration to match the velocity and ensure they aren’t biting off too much, or too little.
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 iteration.
The Why
IPMs help keep business and engineering teams aligned, provide information on the product’s status, and create a structure to collect regular feedback. Importantly, 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 changes 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.
Parting thoughts
It is important to stay flexible and assess these meetings and their value regularly in retrospectives. 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.
Originally published at https://www.defmethod.com.
