- 产品所有者和冲刺主管（Scrum Master）共同决定哪些任务是可以被团队完成的；
As a marketer, you know how difficult it is to organize and execute your projects on time.
For some, it can be a mess of trying to sort out what’s coming next, while you stress about deadlines and more. In other words, your team isn’t working as efficiently or effectively as they could be.
Not to mention you know your team is using an outdated process, which is causing everything to slow down and move at a turtle’s pace.
All of that combined is creating a situation where you want to tear your hair out in frustration.
What if there was a way to change all that?
Agile sprint planning #设计冲刺实操指南# will allow you to effectively plan your work so you can streamline your process and meet your deadlines. You’ll be able to do this and ensure your projects are executed correctly the first time.
This post will walk you through what agile sprint planning is and the theory behind it. We’ll also show you how to create your agile sprint planning process with a full project backlog that works for your team.
Efficient marketing processes await you.
The strict definition of agile sprint planning according to Leading Agile is:
“Sprint planning is a collaborative effort involving a Scrum Master, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.”
In layperson’s terms, agile sprint planning is a framework that helps your marketing team take larger projects and break them into smaller pieces so you can efficiently complete each portion in a set amount of time.
By working in smaller chunks, your team can focus on completing one task at a time as efficiently as possible.
The agile sprint planning process is part of a more extensive agile marketing process. You can learn a little bit more about how agile marketing works in this video#点击观看：5分钟走进Scrum#
Agile marketing is essential for any team because it helps keep them moving as quickly as possible.
Agile marketing forces teams to plan their processes ahead of time and look at their projects as a whole so they can divide work up to increase efficiency. It forces marketers to outline the goals of their project and what they want to accomplish before they even begin.
Essentially, this process helps get rid of vague projects that come together as they go along. Instead of teams being distracted halfway through a process with a shiny new project, they have to focus and get the one they’re working on done first.
Agile marketing also allows you as a manager to maximize the time your marketing team has in a 40-hour week. Instead of some of your workers becoming overworked or underworked, you can see how much time each of your team members uses in a week and plan accordingly.
Here’s a SlideShare on how the process can work for your marketing team:
As you learn more about agile marketing and the sprint planning process, here are some terms and roles to keep in mind.
- Agile Sprint Planning: A process that marketing teams can use to complete projects efficiently and effectively.
- Burndown Chart: A chart that is created during your team’s sprint that shows how much work has been done, how much is in progress, and how much still needs to be completed.
- Definition of Done: The standards of performance the pieces of your project must meet to be considered complete.
- Daily Scrum Meeting: Also called standup meeting. A 15-minute daily meeting between members of a scrum team that reviews work completed the day before, work that will be completed today, and any roadblocks they are running into.
- Project Backlog: A place where all upcoming projects and their tasks and stored away until they are added to a sprint by the scrum master.
- Project Owner: This is the person who is in charge of conceptualizing a project and determining what goals said project needs to meet. They are in charge of coming up with a clear vision to present to the team.
- Scrum: A framework that marketing teams can use to address large complex projects and break them down into smaller pieces to increase productivity and avoid missed deadlines.
- Scrum Master: The person who oversees the entire scrum team and ensures that everyone is productively working. They communicate the capacity and velocity of the scrum team to the project manager to plan effective sprints.
- Scrum Team: A group of five to nine people who are responsible for executing the tasks in a project that have been assigned to them by the scrum master.
- Sprint: A length of time that the scrum team commits to completing a certain amount of work within.
- Sprint Backlog: Tasks and projects that have been moved from the project backlog that a scrum team will commit to completing within a sprint.
- Sprint Cycle: A two- to four-week time frame that a full sprint is completed in.
- Sprint Planning Meeting: A time where the project manager, scrum master, and scrum team get together to assign work for the upcoming sprint.
- Sprint Review/Retro: A time to review what went well in the sprint and what didn’t as well as address why work was or was not completed on time.
- Velocity: How quickly a team can complete work within a sprint.
Now that you know the language that is used for sprint planning, you can begin to plan your sprints. This traditionally involves 17 different steps to complete a sprint from start to finish.
The first step in your sprint planning process is to have your project manager gather information on an upcoming project. This could mean that they meet with a client or stakeholders to find out precisely what goals need to be met for this project.
These goals should be recorded in your template:
During the project meeting, the project owner needs to take notes on what the stakeholders hope to accomplish.
From there, the project owner will turn those notes and goals into tasks that can be placed into your project backlog.
Record those tasks in the project backlog section of your template:
After the tasks have been added to the backlog, the project owner and scrum master will review the possible tasks to see what can be done by the team.
This would also be the time that the scrum master and project owner would determine who needs to be on the scrum team for this particular project.
Add the team members and tasks to your template:
Your team velocity is the capacity your team has to complete work on a project backlog and how often they have completed said work.
Your scrum master can assess velocity with some basic math. Every project your team completes in a sprint holds a certain point value.
So if your team completes four projects that are worth 15 points a piece, your velocity would be 60.
This is something that a scrum master will need to observe and assess over time.
If we went back to our example, let’s say one week your team delivers 4 projects worth 60 points. The next week they deliver 3 projects worth 45 points. So the team velocity would now be 52.5.
Record your team’s project velocity in your template
After seeing the scope of the project, the scrum master needs to determine how long the sprint needs to be to complete the project.
To figure this out, your scrum master would need to take the time estimate that has been attached to each task and total the time.
Then based on the number of hours potential scrum team members can work the scrum master can determine how long the sprint would need to be in order to complete the work.
For example, if a series of tasks added up to 80 hours a week and two team members can each work forty hours a week, the sprint length would only need to be one week.
Remember that there may need to be multiple sprints to complete a project.
Record the length of your sprint and how many sprints your team will need to have:
After the sprints and tasks have been determined, the scrum master will call a sprint planning meeting.
It is standard that every hour of your sprint planning meeting coincides with one week’s worth of a sprint.
So a two-week sprint would potentially need a two-hour planning meeting.
Of course, that’s if you’re doing things by the book. If you don’t need to take two hours, then run a shorter meeting, but don’t go over that time.
At this point, your team should know the capacity of work that each one of them has.
This means that if your content writer only has 32 hours to work in a week, you shouldn’t book them for 40 hours worth of work.
At this point, the scrum master should be pulling tasks up from the project backlog and assigning them to team members. Each task should have a time length attached to it that the team member has to complete it within.
Once tasks are assigned to team members, they are moved into the sprint backlog. The sprint backlog is the amount of work your team has committed to completing.
Record the sprint backlog in your template:
The team members now need to add up the time they have for each task. Once they have their totals, they need to compare the total hours their tasks have and the time they’ll work during the sprint.
For example, let’s say a content writer was assigned 72 hours of work for a two-week sprint. However, they see they have the capacity for 80 hours of work in this sprint. They can either add in additional work or figure out another way to allocate those eight hours.
Total the time for each team member and the allotted time each team member has in one sprint in your template:
During your sprint planning meeting, your team should address any issues questions or roadblocks that occurred in the previous sprint.
Your scrum team should discuss and figure out how to avoid the problems in the next sprint.
Record and document issues and questions in your template:
If everyone on the team agrees on how the sprint backlog looks, you can finalize your sprint.
Once the team is satisfied with their workload the project owner and scrum master will confirm the sprint and it will begin.
After the sprint has begun the scrum team will meet daily at the same time every day and answer the following questions:
- What did you complete yesterday?
- What are you going to complete today?
- What roadblocks that might inhibit progress are you experiencing?
Record roadblocks and notes in your template:
As the sprint progresses, the project owner will update stakeholders on how everything is coming along.
To do this, project owners should check sprint planning meeting notes and the daily scrum notes to see what has been completed by team members, what they’re working on and what still needs to be done.
If a stakeholder wants to see a certain part of a project halfway through the sprint the project owner should be able to check the sheet to see if that’s possible. If it isn’t they may need to talk to the scrum master and have them adjust the team’s course.
This is why having scrum members track and update where they are at with their work is so important.
As your scrum team moves through a sprint, you may need to add or remove tasks based on the progress of the project. If that is the case, the new tasks should be added to the sprint backlog and tagged to show they were not part of the original sprint.
Record those new tasks in your template:
After your team has completed the sprint, the whole group will gather (including the scrum master and project owner) to review the sprint.
Your team should discuss:
- What went well.
- What didn’t go well.
- What could be improved.
- What needs to be stopped to improve the next sprint.
- What needs to be started to improve the next sprint.
Your team will also observe your burn chart at this point in the process. Your burnchart is a visual representation of how your team got through your sprint workload.
After the sprint has been completed and deliverable products have been approved the project owner will present the completed work to the stakeholders.
From there we use our backlog to fill our week long sprints. These short sprints keep us working as fast and efficiently as we can.
From our failures, we learn how to do better and improve. As we improve, we don’t make a mistake again.
The point to this is that you don’t have to use the agile sprint planning in its purest form. You can adjust the process to fit your marketing team.
Now you know all about agile sprint planning. Bring the idea back to your marketing team and try it for a couple of weeks to see if it makes a difference for your team.
We’re betting it will.