DevTeach Day 1 - User Stories for You!

Just sitting through David Laribee's talk on User Stories (well starting really). No code, just fluff. No wait, that's not right. There's no code but that's okay as we're talking User Stories however there's redemption as David isn't cracking open PowerPoint but rather using Keynote on his MacBook Pro.

How do you sell Agile (or User Stories) to your boss? If you're stuck in Waterfall land where there is a design phase, construction phase, testing phase (unit testing phase), and the be-all end-all deployment phase. Agile is about an alternative to getting away from the giant Gantt chart from hell where you're predicting what you're going to do 9 months from now. Projects can't work this way, babies can.

TDD, DDD, BDD, Patterns, etc. are all engineering practices. They're all good and needed. However if all you're doing is these practices then you're just doing a half-baked job. Let's go back to the Agile Manifesto of "Responding to change over following a plan". Agile does have planning and it can be hard, but it's the type of planning that alters the roadmap as you travel along the journey.

Just because you're doing iterative development, doesn't mean you're doing Agile development. There's a term called Scrumifall (and anti-Agile pattern) where you break up the waterfall approach into chunks. What you really want to achieve is more aligned to Analysis/Design/Code/Test/Deliver in each iteration. There is no design phase, there is no testing phase. At the end of the iteration, done is done and released to the customer (but not necessarily released to the public).

How do you work with stories or tasks? There was a good example by Oren on "As a User I want to search the CRM system". This seemed like an epic and for him, involved 3 developers for a month. That's pretty big so a technique is to break this down to smaller pieces (not tasks) so they're more digestible. One rule of thumb is that if your story is longer than your iteration, then it's probably too big on it's own and needs to be broken down.

User Stories have smells too. For example if you have a story like "As a manager I want to approve/reject a document so that...". You might want to stay away from CRUD like functions in your stories. If you've got a CRUD story, you might want to keep them together and not get them too small. Small, but not too small. It's more of an art than a science here.

David mentioned the Story Point Hall of Fame which is a cool idea. The idea is to take a real story where it really is a good example (in your organization) of a 1 point story. Or a 3 point. Or 10. Here's the idea. Put the idea up on a wall, cork board, whatever and tell everyone that this is a good, proven example of a 1 point story. Then other teams can come back and look at the wall to say "That's a good example" and model from it.

How do you deal with inter-dependent stories? A good practice for stories is to follow the INVEST principle (Independent, Negotiable, Valuable, Estimatable, Small, Testable). When you're looking at your story where there's a dependent story the technique to remove the dependency is to fake it out (almost like a mock for user story but it's more of a fake or stub). David calls them connectors and they're basically get the dependency out and create a new story to handle the fake out.