Sprint Planning, What is it Good For?

The first event during an Agile Sprint is the Sprint Planning meeting. The by-the-book purpose of this meeting is for the Product Owner to describe the highest priority features to the team and give the rest of the Development Team a forum to ask questions and break those features down into smaller tasks that get brought into the sprint’s backlog. The team should come out of the planning meeting with a sprint goal, and a sprint backlog. While these two items are very tangible, I have found many other less tangible yet still valuable takeaways from sprint planning meetings. I reached out to our team members to get their input on the value provided and gained during sprint planning meetings.

What value do you provide during, and what benefit do you get from, Sprint Planning meetings?

Tyler Evert

<codeblocktest></codeblocktest>

Sprint planning is the time to understand the particulars of how we’re going to solve problems. This is when we can talk about dropdowns vs. menus vs. checkboxes, on how our data should be structured, and how we’re going to handle testing, upgrading, and deploying. The value I provide is directly related to my 'T-shapedness' as a person. I know a lot about automation, so I’m good at identifying work or issues around deployments and upgrades. I’m also a pretty good developer and I enjoy dabbling in user interface topics, so I’ll happily throw my two cents in there. But most of all I’m listening and learning from the experts on those topics we have. It’s a chance to understand how the product is going to work and learn from the rest of my team.

<codeblocktest></codeblocktest>

Steve Schmidt

<codeblocktest></codeblocktest>

As a user experience designer, I find that Sprint planning meetings provide the first opportunity to consolidate every team member’s thoughts on what solution we need to create for the upcoming sprint. I use that meeting as a mini "design session" - a chance to allow everyone to provide direction and voice opinions on the solution we are about to produce. This gives everyone a chance to buy into the design as well as gives everyone the baseline to use for tasking and effort estimates.

<codeblocktest></codeblocktest>

Sienna Bast

<codeblocktest></codeblocktest>

Sprint planning meetings help the scrum team grasp the details of product backlog items that may be worked on in the upcoming sprint. As a developer, I contribute to these meetings by defining the work and providing an effort from a technical standpoint. Personally, the sprint planning meeting provides me with a deeper understanding of what actually needs to be done, and what it means to the business. This allows for everyone on the team to have a unified vision for the upcoming sprint no matter what their role may be.

<codeblocktest></codeblocktest>

Matthew Wanke

<codeblocktest></codeblocktest>

As a quality engineer it’s my job to make sure that the team is thinking about the quality of a sprint’s deliverables during sprint planning. This ranges from the testing strategy or plan for product backlog items to making sure that the items delivered as part of the sprint will meet the stakeholders needs. At the end of sprint planning, everyone one on the team (including me) should have a clear understanding of what product backlog items the team is committing to, and what it is going to take in order to deliver those items to the stakeholders at the end of the sprint.

<codeblocktest></codeblocktest>

Duane Raiche

<codeblocktest></codeblocktest>

For me, sprint planning is where the entire team comes together and makes sure they're on the same page. It's a two-way street; it's an opportunity to share what I envision a piece of work entailing and to verify that with the rest of the team so that we can all be more successful. This applies not only to technical implementation details, but also to high-level workflow discussions, and gives the business an opportunity to decide if a feature is worth the amount of work it requires.

<codeblocktest></codeblocktest>

Nick Kremer

<codeblocktest></codeblocktest>

I think the biggest thing I get form Sprint Planning, which might be the most obvious as a developer, is breaking down PBIs into tasks to be worked on in the sprint. Additionally, I benefit from talking through the tasks with everyone else on the sprint team as sort of a “gut check” to make sure we’re all on the same page about acceptance criteria; to make sure we didn’t miss anything in previous refinements. This process will usually happen naturally as “taking out” occurs. I also believe (at the very least hope that) I provide some value to the QA member on the team as we talk through the PBI to make sure any sort of testing questions they might have are answered and that it helps them start to think of how they want to approach testing the PBI.

<codeblocktest></codeblocktest>

Have you provided or gained value in a unique way during a sprint planning meeting?

Get your project started today

Get in Touch