Meetings

Meetings are one of the primary tools of communication that help facilitate greater collaboration and faster product development. Here are the different types of meetings that take place and how they should be ran. This isn’t meant to be canon, but a baseline for project managers to adjust and use meetings in ways that best suit their team.

Standups

The most common setup is:

A pre-set time every day. Daily standups only require fixed time and place. Which time and place is up to the team to decide. It is an opportunity to inspect and adapt, a meeting in which the team plans their day.

Keep a time-box of 15 minutes. The purpose of the standup is to give an idea of where the team is. So 15 minutes is OK. Smaller teams may even need less than that.

Standing up. It helps keeping the meeting short, but daily standup does not oblige you to do it standing up.

Every member of the team “answers” three questions:

• What did I do yesterday?
• What am I doing today?
• What blocking issues I have that I need help from the team?

If detailed discussions come up (or to adapt, or re plan, the rest of the Sprint’s work) , it is a good practice to take them offline immediately after the meeting.

It’s best that the product owner has the trello board open during the standup so they can also check to see what’s been done or if there are any stories unaccounted for during standups.

Sprint planning

Sprint planning is an agile ideology based meeting that lasts about 1 hour for every week of a sprint. In sprint planning, the entire team agrees to complete a set of product backlog items. This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint.

Sprint planning usually happens with the product owner/ project manager and the team involved. Collectively, the product owner/ project manager identifies the key stories that need to be accomplished for the sprint and the team works to identify the type of work needed to fulfill the required stories for the next sprint.

Ideally, all the work could be summarized in a sprint goal. Normally front facing, this is a goal that can communicate the overall objective of the sprint. It’s something a client would hear as an update. It doesn’t get too far into the user stories but gives enough detail to have a starting point for conversation.

The user stories come from the sprint backlog. The sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. Each task on the sprint backlog is also usually estimated based on effort. The sprint backlog is normally created from the product backlog that includes all of the potential user stories/ tasks to be accomplished.

Here are some of the key objectives for sprint planning:

Assign a story a point value (estimated level of effort): At kohactive, we use the Fibonacci points to estimate level of difficulty.

Create Acceptance Criteria- We develop testable acceptance criteria so :we know the ideal state for each of the user stories in the sprint

Remove key dependencies: make everyone aware of dependencies- During sprint planning discussion, it gets easier to understand how the current product would interact with the new user stories and how the user stories are connected. It should be a goal to identify any dependencies (backend vs frontend work, client assets, etc) that would prevent the team from successfully completing the user stories in the sprint duration.

Determine Capacity: While it may not be as necessary for smaller teams, sprint planning is a good opportunity to get an idea of how many assets you have on your team. This will help determine velocity

Determine Velocity: Once points are assigned to user stories in the sprint backlog, they form the total points for the sprint. Using historical data, you can identify how much and how long it will take to get the current sprint stories completed.

Determine Commitment: After figuring out capacity and velocity needed to hit all the user stories in the product backlog, the product owner/ project manager can make a determination on how much of the sprint backlog they can commit for completion.

Sprint Review

Sprint Review meetings are an opportunity for the product owner to go over the completed sprint with product stakeholders. During this meeting the team shows which backlog stories they completed. This most likely takes place in the form of a demo of the new features.

It is important to notice that backlog items that are not completed should not be demonstrated. Otherwise this might suggest that these items are finished as well. Instead incomplete items/remaining stories should be taken back into the product backlog, re-estimated and completed in one of the following sprints.

Upon sprint acceptance, the product owner/ project manager should review the timeline, budget, key product priorities to inform sprint planning for the next sprint.

Sprint Retrospectives

Sprint Retrospectives tend to happen right after the sprint review. They are meant to evaluate the previous sprint and Identify ways for continuous improvement. Different teams have the stop, continue, start model.

In this meeting the team members are asked to provide opinions about what the team should start doing, stop doing and continue doing in projects: Start items would be something that the team would like to add to their process e.g. Start coming on time for project meetings. Stop items would be something that the team no longer wants to do e.g. stop checking in code without code review. Continue items will be something team wants to continue doing in future e.g. Continue having daily stand-ups.

The meeting facilitator can set a minimum and maximum limit of a number of items a team member can propose. E.g. Every team member needs to provide 1 item each for Start, Stop, and Continue list and can provide a maximum of 3 items per type. Additionally, once the complete list is compiled, team members can be asked to vote to narrow down the most important items.

This is best done on a whiteboard or trello board so the whole team can see. Best practice is to come back to the items discussed and check to see if they were resolved, implemented, or still an issue for the team.

Product Roadmapping Meeting

While most meetings work in the weeds of the product development process, product roadmapping is meant to allow leadership/stakeholders an opportunity to focus on the bigger vision for the product. Ideally, the conversation identifies where resources will be allocated for future features/ deliverables.

Before you have a product roadmapping meeting, there should be a product roadmap relic at the center of the discussion. The product roadmap includes the key epics, release dates, and other milestones that are normally dictated by the market, users, and/or the client.

During the meeting, the team goes over the follow key areas:

• Business goals and objectives: How aligned is product with the business goals and objectives? Is there a way that product can enhance goals/objectives?
• Product areas: What are the key features/ initiatives/ tasks we need to focus on?
• Order of priorities: Has the priority for ship dates/ customer interest/ resource allocation changed since the last meeting?
• Scope: How much time and people resources will a feature/improvement/ initiative take and how does it compare to the other initiatives

After the meeting, the product roadmap should be updated and shared with other stakeholders. Often times, companies make their product roadmap public for users to see which is a good way to get feedback on what should be built next.

Client Check-in

Client Check-in meetings are a tool for product owners to have a more informal conversation with clients around feelings about the project, questions from the design or the development team, or a chance to help identify blockers. They should be used as needed but it’s good to have informal check-ins more often than less.

Best Practices

Using the Trello Board: Using trello boards for each of the meeting types helps keep a central repository of information discussed and outcomes. It can get very difficult to manage notes from each meeting but opening it up to Trello creates an platform for a product owner/ project manager to crowdsource notes and manage them overtime.

Agenda: For each type of meeting, there should be an agenda. This helps ensure that all participants have a clear understanding of what will be discussed during a given meeting. Another way to think of the agenda is focus more on outcomes. For example, using meeting goals/objectives can help ensure all questions are answered and accounted for in the discussion.

Notes: Taking notes focused on action steps and commitment is essential. This helps keep the team, client, or other stakeholders accountable.