Keeping Scrum Meetings Agile by Margo Rabchenuk & Allen Fordham
Green Paper Versus White Paper
The term white paper originated with the British government, and many point to the Churchill White Paper of 1922 as the earliest well-known example under this name.
White papers are a way the government can present policy preferences before it introduces legislation. Publishing a white paper tests public opinion on controversial policy issues and helps the government gauge its probable impact.
By contrast, green papers, which are issued much more frequently, are more open-ended. Also known as consultation documents, green papers may merely propose a strategy to implement in the details of other legislation, or they may set out proposals on which the government wishes to obtain public views and opinion.
Executive Summary
Agile software development seeks to emphasize ‘people’ over ‘process.’ If your organization claims to be Agile, the needs of the team in the current phase of the project should always supersede rote adherence to rigid processes. This flexibility is one of the things about Agile teams that appeals to organizations seeking to streamline, modernize, or overhaul their digital infrastructure.
Yet for many people involved in Scrum Agile projects, the most conspicuous manifestation that you are in an Agile team is the series of regular meetings (or ceremonies) that are part of every sprint. The constant stream of meetings can sometimes feel burdensome, tedious, and unproductive. Empty chairs may begin to appear during standups. As the project moves forward, temptation arises to combine or truncate the activities, or do away with them altogether.
Is this a contradiction? How can teams reconcile the regimented, constant stream of meetings against the professed Agile core principles of adaptiveness and flexibility? If a team skips or modifies sprint ceremonies, can they still call themselves Agile?
EQengineered’s opinion is that Agile ceremonies can indeed be adapted, combined, or even discarded in cases where they do not serve the project or meet the needs of the team. In this paper, EQengineered reviews why Agile projects have the meetings that they do, and why each of them adds value to a project. Armed with this knowledge, digital leaders can adjust how they approach Agile ceremonies to make sure that every member of the team knows that they are contributing and improving.
Meeting Overview
The lifecycle of a typical 2-week Scrum Agile sprint starts with the sprint planning meeting. Work is estimated, assigned, and approved by product management and the team. Sprint goals are identified, and the sprint officially begins. Once the sprint begins, 15-minute daily standups are held to review three things: what has been done, what will be done, and if there are any blocking issues.
At least once weekly, the team gathers for a set time to review, discuss, and refine the backlog which could include some forward planning and roadmap discussions with product management and/or stakeholders. On the last day of the sprint, the team holds a review meeting for product managers, leaders, and stakeholders to see a demonstration of the work that was completed during the sprint. Then the team discusses how the sprint went in a retrospective meeting designed to understand if any efficiencies can be made in future sprints, and to celebrate achievements.
In total, between twelve and fourteen meetings are expected per two-week sprint. Each core team member can expect to spend three or four hours per week in sprint meetings – up to ten percent of their total time at work. This may seem like heavy process overhead when you have a team that has a lot to do within a project. It may even be tempting to consider cancelling some of these meetings to free up more time for coding. But cancelling meetings can have significant costs to the effectiveness of the team, and these costs will usually not be immediately apparent. Agile seeks to provide a baseline process that teams can follow and adapt, without losing purpose and intent.
This paper provides a deeper look at each individual meeting in a textbook sprint. EQengineered will evaluate why it’s valuable, consider ways to help all participants realize the value of the time spent, and see how the team can focus on the Agile principle of ‘people’ over ‘process.’
Sprint Planning
In the one-hour sprint planning meeting, the team spends time with the product owner and any stakeholders to fill the upcoming sprint with high-priority, high-value work items. This time should be focused on ensuring that team members, stakeholders, and leaders understand where the project is headed, where the team will be at the end of the sprint, and what each person’s responsibility is to bring the project to that point.
Unfortunately, it is not uncommon for teams to feel like time in sprint planning meetings needs to be spent planning the entire sprint from scratch. This can happen if enough time was not allocated early in the project for product management or stakeholders to help inform the backlog's content and priorities. In the absence of a clear plan, topics like ticket prioritization, requirements discussion, and roadmap updates can become the primary discussion topics of this meeting. However, including strategic topics like this may cause the sprint planning meeting to drag on, as the discussion is only relevant to some of the participants. Spending the extra time to review work within the sprint planning meeting can feel tedious, and such discussions are not always relevant to all attendees. Ideally, the backlog and priorities are refined prior to a sprint planning meeting, with some candidate work in the Sprint presented for confirmation by the team.
If the team finds that larger strategic discussions are regularly creeping into sprint planning meetings, consider including a sprint 0 at the start of each new project. A sprint 0 is meant to focus entirely on project planning, project roadmap discussion, requirements gathering, and strategy. Sprint 0 can be used to provide a head start toward building a preliminary map of potential initiatives to target for the first few sprints, which can help give the team a focus as they begin their work together.
If the project is underway, consider including an additional refinement meeting within the sprint to focus on big picture topics. In extreme cases, a remedial planning sprint could even be scheduled mid-project if there is a shift in priorities, requirements, or resources that necessitate a reset to help realign everyone to the new goals of the project. Dedicating time to a sprint 0 gives the team a framework for the entire project, allowing the team to walk in to each sprint’s planning meeting informed about how that sprint will serve the project as a whole. It may feel counterintuitive to address a lackluster meeting by scheduling more meetings, but keeping sprint ceremonies focused on their intended outputs helps to make sure the team’s time is applied productively to the project forward.
Holding regular sprint refinement meetings will make it easier to include work in a sprint. If a team walks into a sprint planning meeting with a nearly-full sprint already reviewed and estimated in previous backlog refinements, the activity of sprint planning becomes assignment and confirmation. Once the sprint is confirmed and a goal is set, the team can begin working right away and the framework is in place as is the team members’ work plans. Depending on the team, a sprint planning session could take as little as 30 minutes if the majority of the sprint is pre-planned and minimal adjustments are needed in order to kick it off.
If your sprint planning sessions feel like they’re lagging, consider the following tips:
Work with the scrum master to ensure a healthy backlog of workable tickets to be considered for the sprint before the meeting begins. If everybody has to wait for the scrum master to fumble through a large unsorted backlog, interest will fade quickly.
Review the goals of the meeting as the first order of business: “When we walk away from this meeting, each of us will know what is expected from us individually and together for the next two weeks. We are here to discuss X, Y, and Z”.
Standups may not be needed on the same day as a planning meeting. Make sure that the team has a chance to give any pressing updates to the team while they are together.
Daily Standups
Once a sprint is underway, contact with the team is managed within 15-minute meetings at the beginning of each day. Most days, the standup will stay under the time limit. However, if blockers are identified, the daily standup can quickly devolve into a discussion and extend it past the time allotted. The scrum master should be firm here to acknowledge each issue and note any necessary follow-up to be conducted separately. Keep track of the blockers and set up time afterwards to cover the issue. All blockers are considered threats to the project until they are evaluated, and timeliness is key for identifying the core issue. Try not to spend the entire standup evaluating the blocker.
While project stakeholders may be invited to sit in on a standup, the only participants should be those with tasks and the scrum master. If meetings are consistently running over time due to increased participation, the scrum master could look to trim the meeting invitation, or set strict ground rules in the beginning of the daily standup to remind everyone about the focus. Once the standup portion is complete, most of the team can drop off and key team members can remain if additional conversation is needed. Attendees who are inclined to get into details should be encouraged to attend refinement meetings to ask the questions and be an engaged participant.
If standup participation feels like it is waning or the team is having trouble keeping the meetings productive, the scrum master may want to:
Ensure that each team member’s update stays topical and brief. If somebody starts getting into extreme detail or if an update takes more than 90 seconds, maintain momentum by offering to continue the discussion offline with a select group of stakeholders.
Emphasize that standups are not the place to hold requirements discussions, project scoping, or code reviews. If you find that the team does this frequently, it might be because the needs are not being met in planning meetings or refinements.
If the team holds virtual standups, the scrum master should own the screen, which should display the project tracking board and focus on each team member’s work.
Remember to update the list of participants regularly. DevOps, for example, tends to have high engagement near the beginning and end of a project, but DevOps team members may not find value in attending every standup for the entire duration of the project. It is permissible to invite someone to standups for several days or weeks and allow them to drop off when their contribution is complete.
Refinement
Refinement meetings are where work gets done collaboratively. The team should use this time to review upcoming work that needs some review and discussion, working with product management and stakeholders to understand requirements and upcoming deadlines. Over time, the meeting can feel redundant. Why have this time every week if work is slow? A few changes can shift the perspective of this meeting in everyone's minds to become one of the most “cannot-miss meetings” within a sprint (besides the demo, of course).
Each sprint will have one or two refinement meetings in most teams: once per week for roughly an hour. This is not a status meeting and should not be treated as such. This is the time to dream big, get into the technical details, and have honest, transparent conversations. This is not the scrum master's meeting, although they will facilitate it. It is the team's meeting, first and foremost, so that they can get what they need to plan future work efforts and understand any technical challenges that come along with an approach. Occasionally, we might hear a team member say, "let's take this offline," which signals that there are other conversations happening outside of the Agile meeting structure which could be taking time away from the team to do the work. How do we correct this and provide value for the team? Optimize the meeting as much as possible as the refinement meeting is a valuable activity that informs future sprints and work.
The scrum master may understand areas about which the team might need more clarity and bring those to this meeting with the relevant stakeholders or product management. Occasionally, teams have used this time to show very early on progress even before a demo to get feedback from a user, or even as a hackathon activity that allows everyone to peer code together to test a hypothesis and bounce ideas off one other. Other teams have multiple stakeholders and product managers that need to be able to contribute to a backlog, so the refinement meetings also act as dedicated "office hours" where anyone can bring questions or discuss upcoming work. In this way, the meeting has direct contextual reference for those in the room, and if there are no pressing issues, the scrum master can default back to reviewing backlog items that need estimation and discussion. This behavioral change for the scrum master can be minimal and as easy as viewing an incoming request and asking if it could be presented to the team in that week's refinement meeting. This keeps the number of interruptions to the team small and the refinement meeting relevant for those participating.
Refinement meetings can be kept lively and relevant by:
Adjusting the tempo of refinements based on the needs of each sprint. This is the most flexible Agile ceremony, and should be scheduled as needed for the current phase of the project. Sprint 0 might warrant three or more refinements, whereas a team that has found its stride and is working through a long list of similar tickets may choose to forego a sprint’s refinement entirely.
Encouraging team members to lead the discussion. The scrum master should cede the floor and let the team discuss what is on their minds, and ask open-ended questions to continue discussion if the floor is quiet.
Approaching team members who are not inclined to speak up with care and empathy. Some team members (especially among software engineers) may not be as comfortable speaking up in a group, but this does not mean that the individuals do not have creative ideas and thoughtful opinions to share. It may be useful to work with individuals beforehand, perhaps asking them to spark discussion on a certain task or topic.
Demo
The culmination of the sprint can also be the most frustrating since not every sprint will have work that is traditionally seen as "demo-able." It's less compelling to share in-progress code than a crisp, polished interface. Showcasing extremely technical concepts like reference architecture can be difficult when nontechnical stakeholders in attendance do not fully understand what is being discussed.
Should partially-completed or in-progress work be demoed? How can the work for a research spike be presented dynamically and satisfyingly? For each contributing member of the team, knowing what to demo and how to present it can be a bi-weekly challenge. This is where the team needs to lean into all the work they did within the sprint. Was there a research spike that reviewed potential work for refactor? Share the approach and some initial findings and the upcoming next focus. Did the team receive some project-changing news that deprecated some of the previous sprint’s work? Share the approach, how this news affects the work done, and what is required to course correct from the initial plan.
All work completed in the sprint is fair game, and discussion should be encouraged. Team members should share solutions that helped overcome a technical problem, or even failed approaches that helped formulate the next test. The keys are honesty and transparency - the demo could be short, but the team should be honest about the work and how it measured up against the goal of the sprint. The demo is a summary of the sprint, and anecdotal information helps inform future work and process needs.
Keep the following elements in mind to maximize the value of sprint demos:
Demos are a good chance to invite additional stakeholders who do not need to participate in daily meetings, but benefit from seeing how a project is progressing.
The participation and approval of leadership is especially valuable during demos. It is a huge morale boost if leadership attends and sincerely applauds the efforts of the team after everyone has shown off their work.
Encourage honesty about which sprint goals were met and which were not. This helps the team refine the effort for next sprint, and eventually the team will get better at estimating their capabilities and achieving their goals. This, in turn, helps leadership build more a more accurate roadmap and make critical decisions regarding team capacity needs and forecasts.
Retrospective
Retrospectives can be uncomfortable meetings. Not everybody is enthusiastic about discussing failures and shortcomings. If a project or team is under pressure, blaming and finger pointing can be very natural reactions, and retrospectives can sometimes feel like a safe place to do this. Even well-intentioned positive feedback can feel insincere or generic.
It will take time for a new team to be comfortable sharing candid feelings about how a sprint went. As a general rule, if you attend a retrospective, be prepared to participate. This is not the time to focus on blame for what went wrong within the sprint; however, it is crucial to acknowledge challenges and overcome them as a team.
If the work suffered from unclear requirements, add more focused questions in refinement meetings and consider additional refinements with the sole focus of that issue. If meeting time presented a challenge for team members in other time zones, review calendars and find a time that works better for the team. If a particular ticket took much longer than anticipated, review the estimation process and see if updates can be made. The key is always communication about the work, the skills and processes needed to hit the finish line, and where the team would like to collectively improve. No one wants to be on a team which is not listening to his or her contribution, and the retrospective is the place to ensure that all voices are heard.
While retrospectives are typically open to the entire team, there are exceptions to this rule so that the team can feel encouraged to contribute. It is not just processes that change during an Agile transformation: the culture of the team changes as well. It may not have been easy to share honest opinions before, and change does not happen overnight. One-on-one retrospectives may happen outside the group meeting if team members need more support to share their experiences and needs. It is important as a scrum master to really listen to your team and pay attention to everyone's actions and see where extra care and empathy should be applied.
To make the most out of sprint retrospectives:
Consider starting the retrospective with a summary of the previous sprint’s refinement to check in on how well concerns were addressed that have already been raised. Discuss what has been done to address the issues that the team raised previously; this will start the meeting on a high note.
Expect the team to give the feedback that they need to give, but try to encourage the team to bring up lessons learned as well as things done well – wins and losses can both be learning opportunities.
Be thoughtful about who is invited. Unlike demos, which often benefit from having leadership present, teams may not be able to have an honest, open retrospective if senior leadership is in the room. If problems are not identified, they are harder to address.
Keep in mind that sprint retrospectives are a time to reflect on recent performance with the primary goal of inspiring the team to fully engage as the project progresses.
Gather talking points over the course of a sprint from standup and refinement notes, and invigorate a lethargic retrospective with open-ended prompts that reference lessons learned that might not come immediately to mind for the team.
Agile Emergence
Agile is meant to drive progress toward a goal. Each individual ceremony is intended to focus on a particular set of outcomes that facilitate quality delivery. In fact, the benefit of a healthy series of Agile ceremonies far outweighs the cost of time spent in each individual meeting.
When led and approached with the whole project and team in mind, Agile ceremonies work in concert to ensure smooth communication and help provide the tools that everyone needs to continuously adapt to and refine the work product. A productive sprint refinement will contextualize the next sprint’s planning meeting. Brief, focused standups will help make retrospectives easier, as the team already knows what is working and what could be improved. Well-attended demos keep stakeholders informed of progress, and stakeholder feedback or refinements can be collected and rolled into future sprints via refinements or planning meetings.
If retrospective meetings are skipped, the ‘adapt’ part of Agile will stall out at the point in the project where the meetings stopped. If stakeholders and leadership are not able to participate in demos and planning meetings regularly, then the vital aspects of a project will be more difficult to track. Work may need to be refactored, since stakeholders were not able to raise issues as work begins to diverge from the initial requirements. Sprint ceremonies build a cohesive story that keeps everyone informed.
Scrum masters have a responsibility to check in with team members to make sure that everyone’s needs are met. In cases where team members may not understand the value of a meeting, the value in that meeting might be more for people with different roles, like leadership or stakeholders. If neither leaders nor team members see value, see if there is room to adopt EQengineered’s recommendations. Then, if it is still not valuable, cancel the meeting. After all, if Agile is dogmatic, it’s not Agile.
Here are a few quick ways to modify your current Agile ceremonies to get the best productivity and velocity:
Cancel standups on days with planning meetings.
Adjust the number of refinement meetings per sprint.
Keep standups (the most common meeting) hyper-focused.
Ask your team what they need.
Model – Coach - Care
At EQengineered, we model the behaviors and actions that we want to have in the teams with which we work. We coach our teams to be effective and foster environments where collaboration can grow and culture can change in a supportive way. We care about the results of our projects and our teams, and applaud all of the great work along the way.
Without putting people first, organizations that are too focused on running a "pure" Agile implementation during their Agile transformation risk falling into the same patterns that they had prior to embarking on this shift in culture and process.
Authors
Margo Rabchenuk – Director | Project Management
With a background in technical project management, agency project delivery, and a Certified ScrumMaster®, Margo is focused on software program and project management practice for application software and web development. Margo is an adjunct faculty member at Rochester Institute of Technology, developing and teaching courses for agile certifications in the School of Individualized Study.
Allen Fordham – Senior Consultant | Project & Program Management
Allen helps enterprise organizations implement modern solutions to problems caused by outdated platforms or under-utilized data. Allen applies his organizational, collaboration, and ‘nerd translation’ skills to help client teams achieve success. Allen is a proud U.S. Army Special Operations veteran, woodworker, husband and father. Allen holds a Bachelor’s degree in International Relations and Affairs from the University of Colorado Boulder.
Editor | Reviewer
Anne Lewson – Director | Program Management and Consulting Services
Anne blends technical with practical approaches to deliver projects ranging from large data mergers to more detailed, analytical solutions for a wide array of internal and external stakeholders. Anne leads the project management practice by using an applied Agile methodology suited to our clients' requirements. Anne has a B.S. in Computer Technology/Computer Systems Technology from University of Nantes and has her PMP and PMI-Agile certification.