Adopting User Stories pt 3: Two Steps Forward

§ May 27, 2008 16:36 by beefarino |

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... 

A Coalesce Filter for PowerShell

§ May 22, 2008 16:49 by beefarino |

Here's a little PowerShell script that acts as a coalescing pipeline filter:

param( [scriptblock] $predicate={ $_ } )
       $script:found = $false;
       $script:item = $null;
       if( ! $script:found -and ( &$predicate ) )
               $script:found = $true;
               $script:item = $_;
       return $script:item;

When used as a pipeline filter, this script returns the first non-null object coming out of the executing pipeline.  Here's a simple example:

$value = @( $null, "first", "second" ) | coalesce;

The result of this script is that $value is equal to "first".  I find myself using this quite a bit for things like default values for optional parameters:

param( $p1, $p2 );
$value = @( $p1, $p2, "defaultValue" ) | coalesce; 

The $predicate parameter allows you to pass in your own criteria as a script block; e.g.:

$p1 = @( $a, $b, $c ) | coalesce { $_ -gt 1 };

will return the first value from the list greater than 1.

Looks a lot like the where-object filter, except that coalesce returns only the first object from the pipeline matching the specified criteria.


Adopting User Stories pt 2: the Kickoff that Didn't

§ May 9, 2008 12:24 by beefarino |

As recounted here, I had the team circle the wagons and pump out a bunch of user stories for an integration project.  It was the first time we'd tried user stories as a means to express requirements, but things felt solid and complete, and the product backlog was full of stories organized by system component and user role, perfect for developing in vertical slices

The project was considered top-priority and had the undivided attention of the company for the time being.  In the rush, I skipped estimating the backlog items and scheduled the sprint kickoff meetings.

Over the product backlog meeting, we iterated through each user story, reading it aloud and discussing in enough detail so everyone understood the feature and the value it brings to the user, but leaving out implementation discussions.  At least, that was my expectation.  The team members uninitiated in the project got flustered with the lack of specificity in the stories.  Some team members seemed to panic, like we had missed a big part of the picture; others got frustrated at the level of intimidation in the room.

The sprint kickoff was a bazillion times worse.  During the product backlog meeting, the product owner hadn't expressed a desire to see a specific set of user stories first, so individuals took the sprint kickoff in their own direction and were adamant to work on features that were obsoleted or purposefully left out of the product backlog.  There was no common ground to be found.  At the end of that sprint kickoff meeting the team had no goal, no milestones, no tasks ... we couldn't even set up the time for our daily scrum.

I've spent a lot of time decrypting what exactly happened.   There were things under my influence, and others outside of my control.  Here's where I think I failed, and what I've taken away from it....


Failure: The product backlog meeting was the first time the entire team had come together to discuss the project.  In particular, it was the first time any of the developers were exposed to the feature list.

Lesson: Expose representatives from each team to the relevant product backlog / user stories before the kickoff.

Lesson: Have the team estimate the complexity of each story, to elicit discussion if nothing else.  Ensure that representatives from development and testing are present.

This seems really obvious, but after a week of daily 3- to 4-hour story workshops I was feeling like the team was familiar with the stories.  Usually there is a lot more effort put on the product backlog than what we did for this project.  The product backlog should be treated like a pet requiring daily attention and affection to remain healthy, but instead we just chain it outside with an open bag of food.  Consider that the team would normally help the stakeholders evaluate priorities by providing rough estimates of the stories in the product backlog.  If one story has a high business value but would take 6 weeks of work, while 3 stories with a greater total value would take one week of work, it may make more sense to tackle the 3 stories in one week first.  Congealing the team on those estimates requires discussion of the features.  We didn't do this estimation because of time pressures - but in so doing (or, I guess, in so not doing), we neglected ourselves of that vital team conversation.


Failure: The user stories varied in specificity from hazy to anal; some overlapped each other; some were really just acceptance test criteria for another story.

Lesson: Focus each story on a user role, a feature, and a business value.  Don't repeat the combination in another story.

Lesson: Express detail and acceptance test criteria as story notes, not as separate stories.

Lesson: Spend the time to refactor the stories and organize the product backlog.

A lot of the frustration in the product backlog meeting stemmed from the fact that some features had a single story, while others had multiple stories, all of them nearly identical save one bit of detail or acceptance criteria.  The perception was that little to no thought had been given to those sparse stories.  I think most, but not all, of this frustration could have been avoided if I had worked with the product owner and customer representative to consolidate and organize the stories before bringing them to the team.


Failure: The sprint kickoff meeting started with a goal vacuum.

Lesson: Force the product owner to prioritize milestones for the sprint before the product backog meeting.

After all, that's the point of the product backlog meeting, right?  To get the team to commit to a specific set of goals delivered at a fixed time.  Not having that goal means the story buffet is open, and each team member will want to do what they think is the most important thing on that backlog.


And last in my list, but certainly not the last mistake I made...

Failure: While the testing, customer representative, and product owner understood the nature of this new user story beastie, the development team did not.

Lesson: If you expect the team to participate in a new thing, make sure they understand its nature.

It's completely reasonable for someone to get frustrated with a process if their expectations of the process haven't been managed.  If I had simply reiterated to the development team that these stories were really placeholders for conversations about the feature that we'd have during the sprint kickoff, it probably would have stemmed a lot of the frustration at the product backlog meeting.  


All in all, it isn't just vinegar; a lot of sugar came out of us trying user stores, which I'll explain in pt3: Two Steps Forward.