We had a lot of problems trying to use user stories as the basis for a product backlog.  We haven't had a retrospective yet, and I anticipate having to wear my asbestos boxers for that wondrous event; however, I have noticed that some of the bigger picture aspects of what I tried to accomplish have established roots in the team.

Phrasing Requirements

One of the things I kept beating into the team's head was Mike Cohn's user story template: 

"As a <user role>, I want to <feature activity> so I can <value achieved>."

Sticking to this template helped us in many ways:

• it pushed the team into thinking from the user's perspective, which greatly improved our ability to communicate about the feature by having a common, iconic user to reference;
• it forced a value statement for every feature, which made blatantly evident the features that were also-rans;
• it made creating acceptance tests a breeze.

Several other projects have flared up at the office, and what I'm seeing is the product owners continuing to use this template to communicate their requirements.  That means better discussion and more acceptance testing.  That makes me happy.

The Need for Accountability

One of the points of using user stories as the product backlog was to enable the team to develop vertical slices through the system - get a single feature working end-to-end - rather than horizontal slices - building up an entire system layer, such as a database or front-end in isolation.  I wanted a cycle of feedback for the team, get a feature into QA for testing, in front of the stakeholders for comment, back to the developers for refinement.  The softer side of the team - by that I mean the product owner and customer representatives - wanted that too.  But the vertical development never happened.  The developers simply would have no part of it, citing various reasons that are locally valid but miss the global point.  Instead, they chose to work on horizontal layers of the system.  Milestones came and went, no features were evident, and QA was sitting on their hands for over three weeks.

The stakeholders brought up the notion of recourse: how would development be held accountable for the missed milestones?  The answer, much to my chagrin, was that they would not.  There is no delicate way to explain the situation, but it may help to understand that the efforts of the developers were praised by their senior manager.  

I've been reeling over this for a week now, my eyes bloodshot from searching for a positive in this dim and ugly situation, and the thing I keep coming back to is this notion of transparency.  Everyone - the team, the stakeholders, and the innocent by-standers - knows why milestones were missed.  So at least we can collectively acknowledge the situation, and that there is a need for holding the team accountable for disrupting the feedback loop.

Or not, depending on the way the wind blows...