It's Feature Time! Making Vision Actionable

User Stories and Epics are inadequate to capture and express critical elements of product design.  User Stories are fine grained and atomic – remember they are “implementable” within a single Sprint.  Epic Stories tend to be semantic free containers of Stories.  Creating sophisticated applications with rich application interfaces requires pre-production activities to validate Epic and User Stories with product design considerations such as usability and architecture. 

We experienced this on our latest project.  Ironically, this was while building an Agile On Demand solution for work management for teams (and teams of teams) using agile methods to create software!  The team had been Sprinting together for quite some time.  Probably in the neighborhood of 15 or more 3 week Sprints that included 3 releases to production of a SaaS product.  As we approached the completion of the third release, we started getting pretty clear feedback from some team members that they didn’t really understand the product vision. 

This perplexed some of us.  We always maintain a product vision.  We refresh it often, especially at the beginning of the release.  It’s not a heavy weight document.  It tends to be about 15 or so PowerPoint slides that capture market, business and product information.  The product stuff is usually high-level Use Cases, release themes, goals, and key high-level features.  We had created these artifacts and reviewed them with the teams before every release.  And in fact, after review, we agreed that the team actually executed against them effectively as well.  So we had a vision, we communicated the vision, our teams delivered on that vision, yet they said they didn’t understand it!

It took some discussion with the team, but we did get to what we believe the root causes were and took action to remedy them.  Firstly, we now communicate vision early and often.  Previously, we were doing the early part.  Communicating vision to teams at the beginning of the release, but we fell short on often.  Now we’ve formalized reminding the team about key elements of our vision at the end of each Sprint in the Sprint demo meeting.  We’ve also employed corporate marketing communication tactics by posting release goals and themes in many of the public areas.

The second remedy wasn’t quite so obvious.  While the team said they didn’t understand the vision, they also meant they didn’t understand why certain User Stories were so important or didn’t agree that others were the right User Stories.  Part of this was that they “couldn’t see the forest but for the trees”.

The teams do use “Story Time” for Sprint pre-planning.  These meetings typically occur towards the end of a Sprint in preparation for the next Sprint.  In Story Time meetings, the Product Owners bring candidate user stories and other items to the team for vetting and discussion.  This allows the Product Owner to have more effective (and shorter!) Sprint planning meetings once the next Sprint starts.  Story Time is a great tool for teams to use to improve User Story quality and make Sprint planning more effective and shorter but typically important planning discussion have already occurred where these Stories were decomposed from broader themes, goals, or Epics.  In our case important people and important considerations were missed during the pre- story time elaboration.

Our solution was to introduce “Feature Time”.  Peter Goubert, our Chief Product Owner coined the term.  Feature Time is a regular (at least weekly) meeting.  It will have one or more specific topics that will be discussed.  The Chief Product Owner coordinates the meeting.  Participants include Product Owners, software engineering leads (or architects), usability experts and others depending on specific topics.  We try and keep attendance as compact as possible.  The purpose of feature time is to look at course grained groups of features, Epics, and Stories and to understand and evolve the product design.  Outputs include preliminary and revised Story backlogs, user interface mock-ups, and high-level domain models.  These artifacts are used to translate the product vision into actionable work for the team.  We also make participants in Feature Time “holders of the vision” and responsible for evangelizing the vision to their teammates.

Keeping teams focused and motivated is both challenging and rewarding.  While agile and Scrum methods are great steps forward for building energy and momentum in application development organizations, practicing them at scale requires us to extend the agile toolkit a bit and we’ve found Feature Time to be an effective new tool!