Live data from Hacker News

Split user stories ruthlessly and get value earlier

mikeborozdin.com

11–20 of 98 posts

Re: Split user stories ruthlessly and get value earlier

#11
post #9

With 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).

I think they had checklist like this: Retro design, quirky, different. I actually like the concept. But the implementation is just terrible.

Re: Split user stories ruthlessly and get value earlier

#12
post #9

With 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).

> But the end result was a crappy car. A lot of features were implemented in a subpar way.

Re: Split user stories ruthlessly and get value earlier

#13
post #5

Where 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.

I think this is where most organized agile implements tend to fail. There's a lot of jumping straight to the user stories and sprints and all that, and skipping over some of the more basic agile ideas, first. One of them is that any artifacts that aren't executable code and test cases is likely to be dead weight that is expensive but delivers almost no business value.

A good agile book will (IMO) even go so far as to straight out say that if you're in a situation where you can't avoid having that level of documentation and paperwork, whether it be due to contractual obligations or organizational culture, then most agile methodologies are probably going to intensify your overhead problems rather than reduce them.

Re: Split user stories ruthlessly and get value earlier

#14
post #9

With 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…

It worries me that I'll paint myself into a corner with Agile one day. Plus, the design documentation gets pulverized into lots of tiny user stories, so it's hard to get new people on board.

Re: Split user stories ruthlessly and get value earlier

#15
post #2

It'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…

For us this is the product owner. They are the ones that do the user studies to backup feature requests with data. It's important to test assumptions about what users want.

This way we don't end up building stuff because someone random thought they wanted it.

Re: Split user stories ruthlessly and get value earlier

#17
Has anyone had good success with enterprise level projects managed in jira?

Background: each story has deliverable value to the stakeholder/

Ask: Download file from vendor, process file with error and success counts, save results in X datastore, email report with stats to specified DL...

Re: Split user stories ruthlessly and get value earlier

#18
post #9

With 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 most important part of agile is the feedback cycle and non rolling release products don't have a very good feedback cycle. it can still help if you figure out pre-release feedback loops but sometimes they are poor representatives of actual results.

Re: Split user stories ruthlessly and get value earlier

#19

Grooooaaaaaaannnnn. The amount of developer hours that go into micromanaging user stories and story points is infuriating

I agree. Also the way user stories are written just makes me want to throw up. "As a user I want to open the about dialog so I can see the version number." Blarghf.

Why not just "Implement about dialog with version number.".

I'm pretty sure 99% of 'user stories' are just feature lists written in a really really awkward and annoying way.

Re: Split user stories ruthlessly and get value earlier

#20
post #9

With 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…

Following your metaphor of the PT Cruiser: it seems like they followed a waterfall process. They came up with a list and then built a car that fulfilled that list without evaluating what they were building st every step along the way. If they'd done it agile-ly, the crappyness may have surfaced much earlier in the development of the car... Maybe early enough to have done something about it. Alas, agile doesn't really work well with design of expensive tangible products like cars.
Post reply on HN