Size Matters: Small User Stories

I've recently joined a team which is in the process of adopting agile/lean methodologies.  This has been somewhat of a challenge since the rest of the organization seems to follow a waterfall approach.  To the rest of the company, we're just a bunch of outlaws slinging software and so it's been difficult to get the buy in from what I understand. We're working towards it, and that's all that matters to me.

I came from a shop which was doing this process quite well.  Prior to that I was in a place where it was pants on fire all the time.  Given the choice, I much prefer the agile process done well. Software got churned out faster and there was less bugs.  Everyone seemed to have a firm grip on a wide variety of the product - there was less of the development silos.

"I want a thing that does a thing like this other thing but different, ya know?"
First and foremost: requirements specifications are important.  The place that had no process was pure insanity.  No one knew what was going on because they didn't really know what was being built.  That lack of knowledge was due to very broad and vague requirements. Without the requirements being specified to any granular level resulted in poor communication and a lot of waste in the form of time re-explaining things.

It sounded so simple when you explained it forever ago...
Big stories are almost as bad as not having any stories.  It's hard to estimate a big story because there is a lot of unknown and a lot of room for change.  The surface area is too large.  By the time you've iterated a big story, the scope is likely to have changed quite significantly from the original simple explanation presented as a afterthought at the end of that meeting you had 3 months ago.  Not only that, but the outside perspective of your progress will seem very slow and your early time estimates will be way off.

What is the smallest deliverable I can provide and still add functionality?
When you've narrowed down your efforts to a very small scope, you have removed surface area for change in the time that it takes you to iterate. That's not to say that feature won't change, because it will.  Once the sprint is done, it's out of our minds and we're moving on.  Change building on existing functionality is good because it builds a better feature.  Change in the middle of implementing functionality is just frustrating as hell.  You just wrote something that no one will ever see.  If they didn't see it, then did it even happen?

That feature demo is closure for you and for the people who sign your paycheck.  They know what you've been up to because they saw it with their own eyes.  They then consciously made a decision to alter direction on something they witnessed work.  Changing something that exists is a lot harder to swallow for a business than changing something that doesn't. I find myself not arguing for a features to be implemented in a certain way anymore because I have less emotional attachment to them once they've been seen.

The other good thing about demoing the smaller deliverables is that your perceived velocity is a lot higher. This is a good side effect because the last thing I want my boss questioning is what I've been doing. For me it also helps keep morale higher because I can get something done fast, get a small pat on the back and then move on.  I stop worrying about where things are going and start worrying about getting the next piece done.

For me, I think the smaller stories provide real velocity gains and not just the perception of such.  I spend less time trying to figure out how the pieces fit together in advance.  Instead worrying more about how this feature fits into what exists already.  If I hit a sticking point, then I know that I need to do some refactoring.  Refactoring code that exists and has tests is much easier than pre-planning all of the what-ifs.

This is all very new to me still.  It's taken me a while to detox from having daily fires to put out. I'm actually able to focus on building better software instead of running around the office with my arms flailing above my head.  As I'm getting to spend more time in agile/lean processes, I'm starting to see big gains in my productivity and mental health. :)

  • Aaron

    What about your blood pressure?

  • http://robtechdiff.blogspot.com/ Rob Simmons

    Good post. Our company does Scrum (top to bottom), and you run into situations where you realize “not all points are created equal”. When you’re estimating story size, you’re factoring in unknown. The smaller you can point size something (by breaking it down into it’s smallest usable component), the more unknown (aka, risk) you’re eliminating. If your team has a velocity of, let’s say 40 points, that does not mean that you’ll be able to commit to finishing three 13 point stories.

    The main commonality I see with failed scrum teams though is the lack of top-to-bottom support, but the company. It’s extremely difficult to get that, and I think that’s where you’ll face most of your challenges. Clients typically want to buy software the waterfall way (except they want the benefits of agile of changing specs every two weeks). Salesmen want to sell it that way. And the head honchos aren’t interested in anything but “when it’s done” – a concept that agile doesn’t have.

    Hopefully you guys will be able to transition the rest of the company to the value of thinking of software in feature-sets, not in “hey it’s done! What’s next?” There’s so much more value there, to clients and the whole company.

  • http://lutzfam.com Philip Lutz

    Very well stated. Good communication plus good management (self and organizational) equals good products. Failure of either equals bad products.

    What I infer from what you implied will likely not be what you meant. I second the need for specifications and requirements.

  • http://swanthinks.wordpress.com Swan

    Great point. We iterate by color to make sure that initially the user stories are kept as short as possible: http://swanthinks.wordpress.com/2011/02/14/product-development-iterating-by-color/

  • http://www.beingsteve.com Steve

    Excellent post! I’ve just introduced Scrum to our team and they’re still far from convinced. Love the “focus on building better software instead of running around the office with my arms flailing above my head” part! :) Good luck with your journey

  • http://bandamatador.com.mx/foro/index.php?action=profile;u=1064194 Mr. T

    I know this if off topic but I’m looking into starting my own blog and was curious what all is needed to get setup? I’m assuming having a blog like yours would cost a pretty penny? I’m not very internet savvy so I’m not 100% positive. Any tips or advice would be greatly appreciated. Thanks

  • http://www.unrarx.com/vanilla/comments.php?DiscussionID=64023 cercei din margele

    Hey there! Someone in my Facebook group shared this website with us so I came to look it over. I’m definitely enjoying the information. I’m book-marking and will be tweeting this to my followers! Excellent blog and fantastic design and style.

  • http://www.aol.com/9df344671a973c23477c6b40e07974d83199d5a6 news

    How come you dont have your website viewable in wap format? cant see anything in my Droid.