Planning Meetings

Scrum has 2 important planning ceremonies. The release planning, to have an overview of all the features we want or imagine what could fit in our software, and the iteration planning to have a short term fixed goal that the team agrees on, and more importantly, a set of features that the team commits to delivering by the end of the next sprint.

For the first iteration that we planned, we didn't separate release and iteration planning, because the project is already in a quite advanced state. We already knew what needed to be there for the release. I think that this is a mistake. Why? Because the release planning is supposed to tell the team WHERE you want to go. It gives a scope to the project, while the iteration planning will tell you more about HOW you will reach the next step. I think it is important to separate these two. We have a different picture of what is coming for the next 2 weeks (our iteration length), and what is coming for the next 2 months. Therefore, we have to watch these two horizons in a different way. Mixing them is just confusing.

The second mistake was in the process of selecting the stories for the sprint. We started our meeting by creating user stories with the product owner (that would be more the release planning). Then, we tried to prioritize them, to know what we would need to include in the upcoming  sprint. Unfortunately, in an attempt to shorten this meeting to let the product owner do what he has to do, we did that without estimating the stories. I thought we could do this later, once we know what we want to include in the sprint, and just with the members who will concretely work on the features. That was a bad mistake. The result was that the product owner wanted everything by the end of the next sprint. Of course! if the stories are not estimated, it’s hard to explain why it cannot fit. :)

Always estimate before prioritizing, even if it’s a quick and imprecise estimate. For the previous reason, and also because based on the complexity of the feature, and the time it might take (understand the price it costs…) the priority will most probably change. Maybe a feature seems mandatory to the product owner, but he might accept to delay it or even to drop it if it’s too much time consuming!

Daily Scrum

As we are a very small company, we agreed that it could be benefit if we would do a Daily Scrum all together, to synchronize everybody on what’s happening at the office. That work very well, and we still keep it under 15 minutes very easily, since we are under 10 participants.

It’s incredible how efficient this short daily meeting can be. Since it has been started, every day has its new discovery of underlying problems that were surprisingly unknown. Good feedback comes from every part : Sales guys are happy to get to know what the tech guys are working on. they have a better picture of what is coming for the customers, and the challenges that other features would bring to the developer teams. The tech guys get to know a bit more what the customer want to hear from the salesmen, what features would be nice to include, and so on. and the management is happy to have a better overview of what everybody is working on, he is finally able to redirect the employee to work on the most important things first. That makes us a little bit more flexible, but still, a lot of work before saying we are agile! :)

However, because everybody is included in this daily scrum, we even more need to summarize the information, and we need to remember that this is not a problem solving meeting. If some problem show up during this meeting, they have to be solved later. This is the only rule that absolutely has to be followed to keep this practice efficient. One other tendency that i have observed is to fall into micromanagement because pigs and chicken are all talking here.