As more organizations adopt the concepts of Scrum and the overall agile development process, more product managers and organizers are having to learn the rules of the game. There are certain guidelines that these frameworks operate within and they must be taken seriously. Optimal results come from each member of the team knowing exactly what is needed of them.
One of the most important aspects of the Scrum process is what is called the Scrum planning meeting. The planning meeting dictates what will be done over the course of the next few weeks in the Scrum cycle, often referred to as a Sprint.
For first timers, this meeting can seem intimidating. However, we have put together a cheat sheet for you on how exactly to run your first Scrum planning meeting. Not only that, but how to make sure even if it is your first time, you will be able to run things like a pro. Let’s get into it.
The goal of a Scrum planning meeting
First of all, before you start your meeting, you need to know what goals you hope to accomplish are. This may sound silly, but there will be some planning before your planning meeting. However, this planning simply includes a few necessities of Scrum.
The main goal for a Scrum planning meeting is simply to divide up the most important tasks of the product backlog amongst the team. The roles that will need to be played are as follows:
- Product Owner: The Product Owner is in charge of organizing the product backlog so that the most pertinent and relevant tasks are at the top of the backlog. This way, the entire team knows what’s what.
- Scrum team: Each developer will take turns within this meeting to take tasks from the backlog that they can complete in the designated time (typically 1-2 weeks). The Scrum team should only be choosing tasks from the top of the backlog (selected by the PO) unless there is a task lower on the list that can be grouped together with one higher up.
- Scrum master: The Scrum master’s job here is to simply facilitate the balance of power between the team and the Product Owner. This is a collaborative project method, but egos and personal preference still need to be taken into account. It is up to the Scrum master to work through those and focus the team on what the end user wants, not what they want.
Now that you have the goals of your meeting down and your team has selected items from the backlog that they want to accomplish, the next part of the meeting can take place.
Estimating availability of the team
A common mistake for first time Scrum masters and planners is forgetting the needs of your team. More likely than not, especially if you choose to outsource app development, your developers will have more than one project they are working on at a time.
Estimating the availability of your team will give you a realistic idea of the work they can handle. For instance, if one member can only dedicate 4 hours a day to the Sprint, they might be able to handle only one tasks from the product backlog. On the other hand, if another developer can dedicate around 7 hours a day, they can potentially pick up the other team member’s slack.
Realistically, most people have between 4-6 hours they can dedicate to Sprint work. Make sure that your team is working on projects best suited for their needs and time. There is plenty of work to go around, so don’t worry if things take a little more time than expected. The idea of Scrum is to be efficient, yes, but more importantly it is to create a great product.
Calculating velocity
Now that you know how much time each member of your team has, we shift out focus to what they can do with that time. Calculating the velocity of your Scrum team is an important part of the Scrum planning meeting process.
This step requires the Product Owner to break down each part of the backlog for the team and work with developers to figure out realistic timelines for when those parts of the backlog can be completed. The time to complete these items cannot exceed the time available to the team, which is why we do this step after figuring out availability.
Once each task and the time estimated to complete it are recorded, we now refer to the Sprint backlog instead of the product backlog. The Sprint backlog will guide the team forward until the next Scrum planning meeting can take place.
Self-organization
In a Scrum planning meeting, no items from the backlog are ever “assigned.” Instead, each member of the team picks the tasks they know can fit within their schedule. This is why it is important to go over availability and velocity before this step to avoid setting the wrong expectations.
Self-organization and volunteering are a key aspect of Scrum. By having each member of your team select what they want to work on, they are more likely to enjoy the work and will likely have an idea in mind when they choose it. This leads to more efficient work, as each member will be working on exactly what they want.
Occasionally, sequencing and other factors may lead one developer to be given a task over another. But, once you get the hang of running a Scrum planning meeting, this is less likely to happen.
Tracking progress
By the end of the Scrum planning meeting, you will have your Sprint backlog filled out. This will contain a list of each task, how long they will take, and who is assigned to them. While you progress through the Sprint, some Scrum experts advise to keep a running tab of each task.
For example, you can write by each task things like To Do, In Progress, Code Review, and Done. This helps the team know where others are in the process and aids the collaborative environment you want to have in your office during Sprints.
Sprint away!
During the actual Sprint, the Product Owner should not and cannot make changes. The entire point of the Scrum planning meeting is to make sure that minimal meetings are necessary until the completion of the Sprint. This means that the Product Owner should be continually grooming the product backlog so that no time is wasted.
Other than that, once the Scrum planning meeting is done, the rest of your team can Sprint away. After you have finished successful running your first meeting, keep in mind areas where you can improve. Take the time you need in these meetings, since this will be the longest you meet until the next Sprint.
By following this cheat sheet, your team will be set up for success and ready to go. Over time you will figure out your own style of running the meeting, but for now, just focus on getting the product done in the right way. After all, that’s what is most important in the end.
The post The Essential Cheat Sheet to Your First Scrum Planning Meeting appeared first on - Snyxius.
