While Agile Sprint Planning is a basic to good agile discipline, what constitutes for good when it comes to Agile Planning is key to a sprint’s success. Join Charles Wilman, James Walker, and Stella Trabucco as they define the what, the who, the when, better yet the good, the bad, and the ugly of Agile Sprint Planning.
Charles Wilman: Hello, and a very warm welcome to all our listeners from us here at MIGSO-PCUBED. I’m Charles Willman, and I’m delighted to bring you our latest podcast on Agile Sprint Planning – a very important aspect of good agile discipline. To talk to me about this, I’m joined by two of my esteemed colleagues. Hello, James Walker.
James Walker: Hello, Charles.
Charles Wilman: And hello, Stella.
Stella Trabucco: Hello, Charles.
Charles Wilman: Hello. Thank you and welcome. So without further ado, I think I’ll jump straight in. If I come to you first, James, what is sprint planning and why is it important?
James Walker: Well, thank you very much, Charles. So yes, I wanted to touch on the subject of sprint planning today. So essentially sprint planning is an event within Scrum whereby the scrum team sets up which work items within the backlog can be achieved for the upcoming sprint.
The main purpose of sprint planning is set out what can be delivered in the sprint and how this will be delivered by the team themselves.
Charles Wilman: Okay, interesting. So perhaps Stella, if I come to you next, who is involved and why?
Stella Trabucco: Well, Charles, this is a very good question. And to tell you more about this, I can touch upon the point of the Scrum Team. They should always be available at the sprint planning event. These consists of the product owner, the scrum master, and agile team members.
Why is this so important? Well, the product owner would be responsible for setting the intent of the sprint. This doesn’t necessarily translate into setting the scope. They would work with the team throughout preparation for, and during the sprint planning to create a sprint backlog.
They also would do various things to support these such as setup a provision, work with the team to define user stories, prioritize the backlog, work with the team to set up the sprint goal or goals, work with a team to slice stories that are two large, and to elaborate where stories are unclear for better estimation.
Then we have the Scrum Master. This role facilitates timeboxes and ensures that everyone is engaged during this event – this is a very important thing. And if you applicable, removes any blockers, which would obstruct agile team members [from] carrying out the work for the upcoming event.
And last thing we have is agile team members, they raise questions, issues around the sprint backlog and decide all together on what work can be fully committed for the sprint. And these are the roles and teams that need to be involved Charles.
Charles Wilman: Great. Thank you Stella. I really appreciate that insight into the different roles that are involved in sprint planning and what they do. So obviously lots of activity there. And so if I come to you, James, how long can sprint planning take and how often and why?
James Walker: That’s a really interesting question here. From my experience team to team, it does vary. But as a general guideline, it is recommended that sprint planning should be no more than two hours for each week of the sprint. So if a sprint is two weeks long, the event is timeboxed to a maximum of four hours.
And if this is a monthly sprint, this will be no more than eight hours. So if the event is timeboxed, this means the event can finish earlier if the team all agree on a sprint goal, and can commit to the work items agreed for the upcoming sprint, which is quite important.
Sprint planning is commonly done at the beginning of each two week sprint cycle, which is fairly common amongst many teams. However, we have to take in factors like complexity, volume, and sometimes uncertainty. Usually you can dictate the length of the sprint planning session.
For instance, say a piece of work that is required happens to have a higher amount of complexity. Then the time box for sprint planning would tend to be eight hours to accommodate for the monthly sprint cycle.
Charles Wilman: Excellent. Thank you, James. That’s really interesting. And I really appreciate the insight you’ve provided there. So I suppose it comes to my next question that we’ve all that considered perhaps Stella you can answer is what is good sprint planning?
Stella Trabucco: Well, Charles having a good spring planning is very important as we all know. And a good sprint planning would take in consideration key things such as: prior to the event there is a well-defined roadmap with a clear vision in mind, ensures the team are clear on the types of features to build, to help drive the product vision forward.
Also ensuring that user stories in the product have been groomed by the product owner prior to the sprint planning. It’s useful to inform the team in the meeting agenda of the items being worked on with the overall sprint goal in mind.
The timebox is well-kept with everybody in the team committed towards the sprint goal. A clear and a great estimator of stories is a critical outcome with the sprint planning to ensure that you know what capacity versus load looks like, and why you can maintain flow in the sprint cadence. Product owners should make sure they’ve prioritized at least one improvement story from the retro.
And last, an example of a good sprint planning would be to have appropriate tooling, such as virtual whiteboard or digital Kanban in place to facilitate an effective meeting. Face-to-face would be better but you know that in the time that we’re living in right now and with everything going on, this is very unlikely to have.
Some examples of what a bad sprint would be: no prior preparation from the product owner on grooming stories, there is no sprint goal in mind, ignoring lessons learned from the last retrospective, technical debt could increase from bugs which were not fixed, incomplete store and spilling into the next sprint planning session leading to lack of product features, and the team are not fully engaged – members are going off topic, there is no people focused on achieving the overall sprint goal, there is conflict boiling over amongst team members and failure to agree on estimate in a quick fashion. So those last would be examples of not to do in a sprint planning, Charles.
Charles Wilman: Excellent. Thank you, Stella. I really appreciate that drawing upon your experience of what does good look like, but I think it’s also important to share experiences of perhaps where it’s not been good for sprint planning. I think my last question around this is that there’s a concept I’ve heard called sprint zero.
Now I’ll profess to not quite know what that’s about. So James, perhaps shed some light on this.
James Walker: Thank you very much, Charles. Yes, I wanted to touch on this concept as it’s not actually formally part of the Scrum Framework. So it’s not a mandatory event that you do. However, I found it very useful when we’ve had to kick off an agile project based on my own previous experience.
So sprint zero within itself is the aim to produce some useful value of a minimum amount of work required by the agile team members. The team itself would have already been formed during the pre planning phase, which differs to when you go into do sprint planning, where you actually have to sometimes form a team.
One of the main benefits of sprint zero is the team already have an idea of the work that’s ahead of them, which helps with the work being both lightweight and also requires a low velocity and amount of effort from the team itself. There are only a small amount of user stories that you usually need for the sprint.
So time for the product to be released to market is made shorter and meeting customer demand in a shorter timeframe. And one thing to add is you get quicker feedback from the customer to add any usable value for the next upcoming sprint. I want to be clear that sprint zero in itself is not a pre-planning method to start a project, just a useful method for teams who are relatively new to Scrum.
Having sprint zero in place is also unlikely to delay the sprint as a team would already have a varying degree of clarity on the work that’s already been produced. So you would already have a small backlog of work ready, prepared for the sprint that’s upcoming.
Charles Wilman: Great. Thank you, James. Well, really interesting insight from both of you there, James, Stella thank you so much for your time.
I think our listeners will really benefit from the expertise you’ve brought to this conversation and what’s Sprint planning is all about. So I hope our listeners have a good understanding now of what it is, the type of roles and perhaps what’s good or indeed a bad example.
James, thank you very much for your time.
James Walker: Thank you, Charles.
Charles Wilman: And thank you Stella for your time also.
Stella Trabucco: Thank you Charles.
Charles Wilman: And to all our listeners thanks for listening. Stay safe and see you soon. Goodbye.
More on the same subject
Choose your language
A monthly digest of our best articles on all things Project Management.
Our website is not supported on this browser
The browser you are using (Internet Explorer) cannot display our content.
Please come back on a more recent browser to have the best experience possible