Bring your system in the planning meeting

Everyone knows that estimating software projects on the long term is hard. Thus, agile teams do it mostly in the context of short iterations.

This estimations happen in a dedicated planning meeting. The way I saw it happening goes like this. The Product Owner spells the story out. The team then tries to figure out the meaning of the story, to understand the implications and, at the end, to estimate.

This exercise has two goals. The most obvious goal is to decide the sprint scope. The less obvious goal is to get the team to have a collective understanding of the stories, to get an overall feeling of implications and identify possible pitfalls.

And it works well. When it works.

Here is the problem. While the theory sounds fine, in practice planning should take into account the existing reality of the system. Most commonly, the implementation of the planning meeting relies on the basic assumption that if you put all the right people in one room they should find the best solution. However, human memory is not reliable enough when you have to deal with millions of details.

The current state of the system matters a great deal when reasoning about a new feature, its possible implementation strategies and their implications. Thus, the system must be made integral part of the conversation. The facts must be invited at the round table.

"Wait," you might say, "it's not like people do not want to have accurate facts." Indeed, it's not. But, they still do not do it. The main reason for this is that retrieving facts is perceived to be an expensive operation. Only it does not have to be expensive at all. All it takes is you to invest in your assessment skill.

Let me give you a couple of examples.

In one case, we had to estimate a story around the communication between two different systems. Let's call them the Emitter and Receiver. The new story required that when the Receiver received a message from the client side of the Emitter, the user interface of the Receiver had to refresh. Nobody in the room knew much about how the communication happened, but we knew that if the communication was directly going to the Receiver server side, we would have had to build a whole infrastructure for refreshing the user interface. However, if the communication would already pass by the Receiver's client we could simply hook in. As a consequence, the estimation could have gone from small to large.

To figure out the best way to go, we set up a little experiment:

• we placed several breakpoints on the server side of the Receiver;
• we triggered the behavior from the user interface of the Emitter;
• in the debugger, we looked up the stack to see if we see any class belonging to the Receiver's client.

And we found that the Receiver's client indeed was involved. So, we decided that the solution would be cheap, and we felt good about it (it also turned out that we were right to feel good about it). The whole experimentation and follow-up discussions took less than five minutes. During these five minutes, the discussion continued, and when the information came in, we just picked it up and went with it.

At another time, the team had to approach an older part of the system that was developed by others. When it came to stories, the discussion got swamped simply because the engineers could not relate to the topics, and the estimations were all over the place. They could not picture possible solutions because they did not know what existed already. Both the team and the Product Owner got frustrated and the atmosphere was anything but positive. To brake this cycle, we stopped and took some 10 minutes to identify things we would like to know about the system. During this time we also looked the information up both using the regular code editor and more sophisticated tools like Moose. We then went back to the drawing board and suddenly the brainstorming became more fluent and constructive. Those 10 minutes made all the difference.

Your system matters. You can ignore it in the planning room, but the reality will bite you during the sprint. Instead, bring (at least) a laptop with you in the planning meeting and be ready to experiment. Whenever the discussion relates to the state of the system, think of a little experiment or analysis and look up the information. A practical way to not get everyone looking at their laptop all the time, is to appoint a facilitator to look up facts quickly, and have the rest of the team focus on the high level brainstorming.

It won't work flawlessly from the very beginning, but you will be surprised to notice the difference.