Yesterday I met with our senior designer, our lead developer, and our product manager to discuss the design and functionality of a feature we plan to build out later this quarter.  Our current sprint has barely started and already we are talking about what we plan to work on in the coming weeks and months.  Why clutter up our busy schedules with a meeting that doesn’t have anything to do with the intense development work we are engaged in for the next two weeks?

The reason relates to concepts that Marty Cagan discussed in a newsletter about what he calls the ‘dual-track scrum’ which you can read here: http://www.svpg.com/dual-track-scrum/.  I’m a big fan of the ideas from the Silicon Valley Product Group and have a link on the sidebar of this blog.  In this particular piece, Marty begins by describing a problem he has encountered that I have seen as well.

When I first start working with an Agile product team, one of the most common situations I find is where the teams have long and frustrating Sprint planning meetings because backlog items are poorly defined and not well understood; they have slow velocity as well as poor design because details are still being worked out during the Sprint; and the amount of waste and rework is very high because backlog items have not been validated.

In other words, individual sprints can be frustrating and unproductive unless two issues are taken care of before the actual development begins: validating that the idea and its accompanying user experience will resonate with the market and planning the approach to building out the idea.  One of the key ways we seek to avoid this frustration is by taking some time this sprint to plan what we will work on next sprint – and even some things we will work on beyond that.  And so we met on day one of our current sprint to talk about a feature that has been on our product roadmap for over a year and that we plan to work on some time in the next few months.

The product manager and I had discussed the idea previously.  We had met with some of our client advisors to uncover a problem among the clients they serve and to make sure we had a good basic understanding of the functionality we needed.  Then we called together our senior designer and our lead developer to share with them our understanding of the identified market problem and to begin discussing how we might tackle the issues.  We all left that meeting yesterday with key next steps: further validating the right workflow with some of the clients who will use this feature, sketching out wireframes for how different aspects of the feature will function, and looking into possible development avenues for how this new functionality will be both built and integrated into our existing offering.  We didn’t want a detailed specification document; instead our goal was to think together toward a well thought out conceptualization of the problem so that the development team would have a solid foundation to begin from.

With a two-week development cycle we need to hit the ground running from the start of each new sprint, and that means we cannot afford to spend the first few days figuring out what we intend to work on.  For this reason we spend some of our time each sprint validating and planning for features we intend to develop in the future – fleshing out user stories and thinking through the different pieces of the problem that will need to be solved.  Laying this groundwork now makes it much easier to be confident about what we will build in the future.  Of course, in truth it’s not that simple.