Banish long Sprint Planning meetings

In the Agile world, a Sprint Planning meeting would typically have the Business / Product Owner listing and explaining each story to be delivered and the team goes about doing their best to understand each story based on questions and discussions. The team then estimate the effort needed for each story and commit to whatever they think is feasible within the Sprint duration. For a 2 week Sprint, this typically takes around 3-4 hours.

In many cases, discussions on stories unearth scenarios that need further Analysis by the Product Owner before they can be ready for development. These stories cannot be picked up for development even if they are of highest priority since there are some unknowns about them. This means that the Sprint backlog could consist of stories that are not of highest priority. Also, this results in a long Planning meeting due to more discussions and more stories to discuss.

Is there a way to change this and ensure that the Sprint backlog is filled with stories of highest priority and value? Also, is it possible to have a shorter planning meeting?

Fortunately, the answer is Yes…

The key is to remove the discussions and visit all possible scenarios up front.

The answer is to have an Elaboration session for the next Sprint in the middle of the current Sprint. The Scrum Master gets the team and the Product Owner together for the Elaboration session. Here, the Product Owner presents the stories for development in the next Sprint and solicits questions and feedback. The team and Product owner discuss all possible scenarios and get a complete understanding. There is a huge possibility that some stories might not be ready for development. The Product Owner then has the time to action these before the actual Sprint planning meeting a week later.

This way, the team is fully aware of the stories coming up in the next Planning meeting, the Product owner has time to fine tune his high priority stories and many stories can be committed to and taken up for development without much discussion at the planning meeting. All this leads to a short planning meeting and a less stressed out team. The additional meeting that is added would provide value by unearthing issues up front thus providing enough time for resolution.

I strongly encourage management and teams to try this option out. Do let us know how this worked for you.

Developers will be idle soon, why are you not creating user stories?

A few years back, a senior engineering manager kept a stern face and told me “The developers will be idle from next month as you seem to have no more user stories lined-up for them. I will withdraw them from your product and they will not be available when you need them”. I looked at him flabbergasted. When on earth was Product Manager’s job to create work for developers? A Product Manager’s job is to run the product’s business in a profitable manner; in the process if there is work for developers or sales or support – that is only a consequence of it. I have seen Product Managers succumbing to such statements by:

- Developing features which have low business value – thereby creating a monster which needs to be supported for years to come

- Developing supplementary services which do not align with the overall vision of the company

While such a statement to start with was myopic, so are some of the reactions. During “lean” periods there are productive ways to make the best use of the time:

  • Solve technical debts. There may not be any immediate business value, but in the due course this will pay off by lesser maintenance cost and faster implementation of new features. Again, identification of the right “technical debt” to solve is a challenging task which the product manager must engage the Architect and other senior technical specialists of the product.
  • Take your developers to the customers: Some organizations have institutionalized customer visits by all members of the team, while some restrict it to the product managers and sales. This is a great time to take the development folks to meet customers in a “no agenda” fashion to know how they use the product and elicit “pain points”. These visits give a great insight into the customer, which usually results in greater sense of commitment and involvement for the participants, having known what their creation does to lives of people.

Use lean periods wisely.