Life, Teams, and Software Engineering

Category: process

Why "User Stories" Failed Us

NOTE: Please read this entire post, I don’t aspire to become the Winston Royce of User Stories. :)

About 7 or 8 months ago our teams decided to try using User Stories as our primary mechanism for capturing requirements.  Since then, we have taken our lessons learned and have moved away from them.  The reason for their “failure” is laughable really: people couldn’t get past the name.  There were team members and customers that just couldn’t get beyond the fact that they’re called “User Stories”.  People would make cracks about Epics and ask whether it’s more like Odyssey or Gilgamesh.  In the beginning this was funny, and we had a laugh, but some people just couldn’t get past it, and we have since decided to phase out the use of that term.

The levels of success with User Stories in our group vary greatly, but as with any two projects you can’t really compare them based on a single part of their process.  The team I am supporting has delivered value consistently since the project started and we have done so not because we used User Stories (we did, and to great effect I might add) but because we were (and are) disciplined.  Other teams call functionality “done” without having high level tests against it that can be easily repeated.  I blame myself for those failings if for no other reason than I should have noticed the signs.  Someone has to, right?

On my current team when one of us starts to get lazy the other half of the pair straightens them out and makes sure that everything they thought to test has been tested, and that it’s in the appropriate place for our automation infrastructure to get at it.  We commit a change and within an hour we’ve validated (yes, that’s validated, not just verified) that latest version against all our user stories to date, against all supported configurations, including protecting ourselves from regression.  We are able to answer the question “when will version X be done?” using real-time data because we keep Jira up to date and because we understand what “done” means.  We don’t fool ourselves into thinking we can do more work in 3 weeks than we’ve historically proven we can do, and we don’t let management pressure us into committing as such.  We’ve learned to how to adjust our sprint caps for personnel fluctuation as team members are temporarily stripped away to work on other things, which happens quite often.

Like I said, it’s not the tool’s fault.  It’s unfortunate that something so trivial could kill its use in our process.  Now we work on “Features”…that contain shorts blurbs about something succinct that the system should do…and are estimated using points…  Sound familiar?  User Stories are no more or less valuable as an artifact than “shall” statements in more traditional requirements management methodologies, but they’re tight, to the point, and no one fools themselves into thinking they can craft the perfect sequence of words to build the perfect statement.  No one even tries.  Instead, the focus becomes the user’s intent, not the words in the requirements document.  And intent is best captured with higher bandwidth forms of communication, like getting everyone in the same room and talking it out.  That, I’ve learned, is the true power of User Stories; even if they’re called Features.

Processes That Work For You

All processes have their pluses and minuses.  Many teams on each side of the ‘agile boundary’ think they’ve got it right, and they may, but it’s not which side of the boundary they’re on that matters.  What matters is that they’ve managed to find processes that work in context.

Maybe you’re on one of these teams.  Maybe they’re mythical to you.  Either way, what a stripped down process framework like Scrum gets you is an opportunity to find what works for your team not just because your processes/practices haven’t failed you yet, but because you’ve felt the pain the absence of that process/practice causes.  I’ll say that again because I think it’s worth repeating.  We want to be able to say our processes work not because they haven’t yet failed us, but because we know exactly what will happen if we remove them; because we’ve experienced it first hand.  A major advantage of the shortened feedback loops of Scrum (or any iterative process) is that it allows you to frequently look at your problems, find their root cause, and come up with a way to fix it.  I’ve seen time and again that existing “traditional” practices are quite often the remedy.  I’m not the first to suggest “home-grown” processes but I do believe it’s a good approach, perhaps the best if you can afford the effort and really dedicate to it.  Just like we wait to plan and estimate until we have the best information we’re going to have (i.e. ‘the last responsible moment’), why not apply the same methods to process adoption?

Now I’m not suggesting we start from ground zero, that would be foolish.  Obviously we use version control, somehow elicit and track requirements, some form of configuration/requirements management, etc, but those are all just tools.  The processes and practices that you choose to employ (i.e. Process Areas) should come from need.  Choose a responsible starting point and grow your processes as you find need for them from that point on.  If it’s required that you meet CMMI Level 3, so be it, but you should still revisit your processes frequently (and hope that whatever governing body levied that requirement is willing to accept the added cost and possible, or inevitable, waste).

It’s also perfectly acceptable to discard processes that cost more than the value they add, or to replace them with more appropriate ones.  That’s the beauty of retrospective.  After all, a failure across two weeks or even a month is better than a failure after a year of churning.  That is if you can course-correct as necessary.

No matter what side of the agile boundary your team works on, you should regularly evaluate your practices and processes.  Ask these questions with your team:

  1. Do we really need to be doing this?  What happens if we omit this?  Would it be responsible to omit this?
  2. Can we be doing this better?  If so, is there anything specific we can implement immediately?  Anything we need to investigate further?
  3. Does it feel like we’re missing something?  Is there a practice or process we can introduce to fill the void?
  4. Is something consistently going wrong?  Why x 5
I’ve found that keeping a consistent eye on these things allows us to make changes quickly and effectively without sacrificing overall quality, or any number of other benefits various processes can provide.  All processes aren’t all right for all situations.  Build what works from experience, from pain, from failure, not just because some book or group tells you so.

Copyright © 2017 Life, Teams, and Software Engineering

Theme by Anders NorenUp ↑