As a scrum master, I am usually asked all kind of questions about agile as a methodology. Some people explain to me why agile doesn’t really exist and in other cases, people tell me about their great adventures in the agile land.
The most popular question by far is “what is the most important ceremony in agile?”. There isn’t a right or wrong answer to this question, all agile ceremonies are equally important for an agile team.
Recently though, I started categorising these ceremonies depending on the nature of the work that the agile team is doing. A team working on an internal product for an organisation might find the daily standups more important than the other ceremonies due to the fact that they already know the product and that the product owner is usually someone within the business that is in most cases present in the standups.
Now imagine another scenario where the team is hired to work on a project for an external client. In that case, and this is my opinion, the planning meeting is the most important ceremony for the agile team. Getting it right will, most likely, make the project a success. Since I’ve been working in that scenario for a while, I would like to point out the “not so secret” secrets of a successful planning meeting. I promise that I will dedicate some time to go into more detail on other ceremonies in the near future.
Let’s have a video chat to save time, face to face is overrated
The “story” of my life… (got it?)
Talking about the scenario of the external client… I mentioned that the most important agile ceremony is the planning meeting. I also mentioned the importance of getting it right.
But how do we get it right? What is right?
Let’s start the other way around, how do you get it wrong before even starting the planning meeting? The answer is easy, by not respecting the actual planning meeting. By not dedicating time and the energy to it. A good sign for that is by not inviting the product owner to the meeting, and I mean physically. A big mistake that many teams do is to underestimate the power of having the product owner in the room.
By inviting the product owner, it doesn’t only make the gathering of every detail easier but also shows to the product owner that the team value the planning meeting.
Don’t get me wrong, a video call can be valuable if the backlog is in good condition and the team is clear on prioritised stories. It is more of the exception than the rule.
It is all about the biscuits
Preparation is everything and a successful meeting needs good preparation. First thing in the list of success… the biscuits. I love biscuits, I cannot imagine a productive conversation without biscuits. As you can understand, biscuits are always in the middle of the table during the planning meeting. I love getting bourbons and making them into Jenga tower. Why bother you will ask, and the answer is simple, it breaks the ice when the client walks into the room. Everybody is talking about the Jenga tower and this is a win in my book. The last thing we want is an odd silent 15 seconds at the beginning of the planning meeting.
Down to the business now, we had the biscuits and the nice coffee so it is time to talk about the project. We will assume that the backlog is prioritised (as part of the backlog refinement, another agile ceremony that we will talk about in the near future, as promised earlier) and there are some designs or wireframes already prepared. It is worth mentioning that the whole agile team is included in the planning meeting (developers, testers, designers, scrum master).
Everybody loves a demo
We start the planning meeting with the demo of the work that the agile team have done in the previous sprint. A member of the team presents to the product owner the work and answers any questions they might have. Once this is done the team review the tickets in the sprint and explain to the product owner how the sprint went, and they answer any questions, especially when stories are not completed as expected. This is an open and honest conversation, after all a successful project is built in trust. Unfinished stories are moved to the backlog and prioritised accordingly. They will be re-estimated before they are moved to a future sprint.
Getting things (or the story) done
At this point, demo and sprint reviews are done and it is time to move to the planning for the upcoming sprint. It is very important to have the designs on the wall, visible to everyone. It is also important to have the backlog visible on a TV for the team to discuss the prioritised work. Imagine now that in the room all the designs are in front of the whole team and the backlog on the screen next to the designs, this is when the magic happens. The product owner selects the first story to go to the sprint and the conversation begins.
Before I continue with the details on the planning meetings it is important to point out that we keep the same format for all our stories to make everybody’s life easier. Maybe another thing to talk about in the future?
During the conversation, the agile team and the product owner will discuss all the details about the story. The designs will become the main focus of the conversation, I love asking the obvious question, “What happens when I press that button…” and I have to admit… I also love the silence in the room that this question might create. The whiteboard is in full action as well, with lots of ugly but useful wireframes of the expected behaviour. I have discovered that the uglier the drawing the better the result. I have to admit, my drawing skills are below average, to say the least.
But this is what this meeting is all about. Getting all the detail before the team can start the work. The team might spend more than 30 minutes discussing a single story but this is not an issue, I would say it is the contrary, the team needs to understand what is delivering. In most cases, there are several ways that a problem could be solved. It is very important to explain these options to the product owner and suggest the best one and then let them make the decision based on the needs of their business. Remember that the client has the bucket with the points they can spend and they have to make the most of it.
An interesting trick I usually do is simply asking a member of the team…
“So we talked about the story and we are going to develop it and then test it and finally say that it is done. What should the product owner expect to see in the next demo?”
This is it, there are 2 outcomes from that, we either all agree with the answer or we will end up spending another 10 -15 minutes talking about what we actually said we will deliver. It is very common to hear a member of the team saying that once a story is done then we will deliver feature x and y but then the product owner to say that they were expecting feature z as well. Nothing is wrong with that, the important thing is that after the meeting every single person in the room is on the same page and know exactly what each story means.
Everything in this process is perfectly fine and healthy. As I mentioned earlier it is all about good communication and trust. After all, you can only estimate a story correctly when you have all the detail explained. And this is actually the next part in the planning meeting, the estimation.
The team now knows what is expected by the end of the story and they can estimate the amount of effort that is required to complete it. I like this part because we are using the scrum poker to estimate, and even better, we are using our phones to do that. Nothing wrong with shaking the phone to reveal the estimation. I can see another potential blog about estimation coming in the near future. Did I promise too much?
Once all the stories to be in the sprint (plus a few more in case the team need to pick some from the backlog) are estimated, then the team is ready to start working on the new sprint. Before that though, a build with the stories from the previous sprint is delivered on the same day or the day after the planning meeting if the product owner is happy with it.
Here is a list of a few key points to keep in mind when walking into your next planning meeting:
- Keep the atmosphere light in the room, biscuits and ugly drawings are there for a reason, and the last thing you want is a boring meeting that everyone wants to escape from. We don’t like boring.
- Knowing what needs to be delivered is important, don’t rush this meeting. Let the team discuss each story for as long as is needed. Obviously, make sure that they don’t go off topic.
- Exchange opinions and make use of the designs when possible. They hold many answers… or questions in some cases.
- Present different solutions for a problem, suggest one and let the product owner decide the best one based on their needs.
- There are no silly questions, ask anything you think is important to get the job done.
- What did we say we would deliver when a story is done? 😉