Split user stories ruthlessly and get value earlier
mikeborozdin.com
Split user stories ruthlessly and get value earlier
1–10 of 98 posts
Re: Split user stories ruthlessly and get value earlier
#2It's easy to spot when agile webdev types don't do this... you end up with a responsive mobile site that is missing half the features that you want.
It's easy for sharpie commandos to sort interactions by priority and build a user story that hits most of the priority interactions. Splitting isn't natural especially when the designers aren't very experienced.
IMO somebody representing the business who isn't a designer needs to be in the approval process to throw back work when all of the necessary interactions aren't captured.
Re: Split user stories ruthlessly and get value earlier
#3This is all correct, and following this advice will improve your project planning. BUT it skirts the problem that Agile makes people think they can plan a project without knowing what's a functional spec, what's an implementation plan, and what of those things is implied by a user's desires. You can't arrive at a really good plan just writing more-concise stories that don't span too many hidden requirements. It helps, but it isn't a substitute for domain knowledge and systems analysis training.
Re: Split user stories ruthlessly and get value earlier
#4It's easy to spot when agile webdev types don't do this... you end up with a responsive mobile site that is missing half the features that you want. It's easy for sharpie commandos to sort interactions by priority and build a user story that hits most of the priority interactions. Splitting isn't natural especially when the designers aren't very experienced. IMO somebody representing the business who isn't a designer…
> IMO somebody representing the business who isn't a designer needs to be in the approval process to throw back work when all of the necessary interactions aren't captured.
Critical in my experience. I usually call this the "smart ass SME" (subject matter expert).
Or, "Go out on the floor and find me someone who does the work every day, has been doing so for a decent amount of time, and who still complains when things are broken and has no problem speaking up."
I can tease out issues from a generic complaint. I can't from silence.
The other thing you'll find they're useful for is throwing out ass-backward use cases that seem logical to management (and me) but are stupidly inappropriate for some obvious reason to an actual person doing the workm
Re: Split user stories ruthlessly and get value earlier
#5Where I work now they have attached too much overhead per story. Time tracking, statuses in jira, separate confluence page with stringent rules about the content etc. So we now make huge stories in order to actually get to spend some time implementing stuff.
Re: Split user stories ruthlessly and get value earlier
#6Reminded me of Paul Hammant's posts:
- https://paulhammant.com/2012/04/24/call-to-arms-average-stor...
Re: Split user stories ruthlessly and get value earlier
#7Reminded me of Paul Hammant's posts: - https://paulhammant.com/2012/04/24/call-to-arms-average-stor... - https://paulhammant.com/2012/11/12/smaller-stories/
And Mike Cohn's SPIDR tips for splitting stories:
Re: Split user stories ruthlessly and get value earlier
#8Following a chain of links and a google search, I landed at this podcast episode which I really liked: http://talkingcode.com/podcast/episode-14-jeff-patton/
It's an interview with Jeff Patton, who seems to be a pretty well-known name when it come to user stories and story mapping, and I really enjoyed his take on this matter.
Re: Split user stories ruthlessly and get value earlier
#9With a lot of agile stuff I feel like you tend to end up with a result like a PT cruiser car. Some years ago I rented one and they had done everything right: Interesting design, cool features on the inside, analog clock on the dashboard and everything else. They had checked off all user stories of the car.
But the end result was a crappy car. A lot of features were implemented in a subpar way. Nothing really fit and the car just didn't "feel" right.
With strict agile structures I feel the same happening. You check off stuff and on the surface you are doing everything right in a methodical way. But there is no mechanism to check if the overall result feels right and has cohesion.
Re: Split user stories ruthlessly and get value earlier
#10With a lot of agile stuff I feel like you tend to end up with a result like a PT cruiser car. Some years ago I rented one and they had done everything right: Interesting design, cool features on the inside, analog clock on the dashboard and everything else. They had checked off all user stories of the car. But the end result was a crappy car. A lot of features were implemented in a subpar way. Nothing really fit and…
I don't think I've ever heard anyone compliment anything about the PT Cruiser before. From what I've read, they did everything wrong (assuming you want a car that drives well and lasts a long time, and doesn't look hideous).