![]() The flat backlog is poor explanation of what a system doesĪrranging user stories in the order you’ll build them doesn’t help me explain to others what the system does. Let me describe what’s wrong with story writing, then generally what a story map is – and why it solves problems for me. However, I’m seeing more and more people arrive at similar approaches – so at least I know I’m not too crazy. Years later, I still love the approach… so much so that I’m in danger of seeing it as a “ silver bullet” – which is an early warning sign that I’m becoming a dogmatic fool. I first wrote about this approach in the article “ How You Slice It.” The article was published in January 2005 – but by the time it was written, I’d been using the practice for a couple years. I’ve been using a practice I call story mapping. I had fun – and I was pleased to see the group really get into it and feel good about what they came up with. We had what I feel like was a pretty successful couple days of story writing and release planning. I’m writing this from the plane as I fly back from a client site. The backlog puts those pieces in build order – from highest value to lowest value – which is great if you’re a project manager – which I’m not. ![]() #THOUGHTWORKS PRODUCTS STORY TRACKER SOFTWARE#Well not completely dumb, in that if I’m going to build software incrementally in small pieces, I’ll need to figure out what piece to start with. One of the more troubling things, for me, about common Agile development practice is the idea of the flat user story backlog. And, the user story backlog we built that first day of discussion still describes the same high level view of Mimi we saw then – minus the stories we moved out of the release of course. As of this writing, Mimi currently sends close to four million messages per month. Mimi shipped after a lot of sweat and effort from Gary, Dave Hoover, and the fine folks at Obtiva. What’s more, building a piece of commercial software that made the job of sending out mailers easily and quickly seemed like a good idea. By the end of the mapping exercise, all the other music related things Mimi could have done seemed like a tall order. It was too big for a single story – too big for an “epic” really… it took most of the map to think about all the details of designing a promotional mailer, building up an audience list, then sending out the promotion, and tracking responses. ![]() However, when it came time to prioritize we focused on the band member promoting a gig in a club. In Gary’s case he originally set out to build Mimi – short for Music Industry Marketing Interface. ![]() When it comes time to prioritize, Gary did so with the entire context of the system in view. Building a user story map helps us focus on the big picture – the product as a whole instead of getting myopically focused on an individual story. Gary and I worked together for a day to build a user story map – a better version of a product backlog. #THOUGHTWORKS PRODUCTS STORY TRACKER HOW TO#Why the flat user story backlog doesn’t work, and how to build a better backlog that will help you more effectively explain your system, prioritize, and plan your releases. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |