Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Split user stories ruthlessly and get value earlier

mikeborozdin.com

Post reply on HN
Print view View original

21–30 of 98 posts

Re: Split user stories ruthlessly and get value earlier

#21

Post by Domenic_S »

IshKebab wrote: post #19
bonoetmalo wrote: post #16

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.

A user story is not a complete spec.

The requirement you wrote makes it easy to accept it as a complete spec (just implement this!), when it isn't.

The user story you wrote prompts more questions -- what's the dialog look like? Do we display the whole version number? Does the dialog contain anything else? How does the user close the dialog? Where does the user interact to open the dialog?

Re: Split user stories ruthlessly and get value earlier

#22

Post by Domenic_S »

bonoetmalo wrote: post #16

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

Number of developer hours should be nearly nothing. A couple per week.

Done properly, these things should keep you from getting halfway into implementing something, having a question nobody thought of, and getting stuck. Then stashing your work and moving on to something else while the original feature lingers half-done or dies altogether, either way the timeline got blown.

This is only possible (the time savings I mean) if you have a PM or product owner -- making devs do that work is madness.

Re: Split user stories ruthlessly and get value earlier

#23

Post by sixdimensional »

forinti wrote: post #14
maxxxxx wrote: 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.

I use a technique where I can visualize user stories as if they were part of a regular functional specification. It involves categorizing user stories into features/functions on paper first, and then entering them into our agile tracking tool, and then keeping the paper up to date when new user stories come up.

I use dot notation for functional specification grouping into features to uniquely identify user stories, which get tagged in the user stories in the tracking tool. Often they look like "Admin.UserManagement.CreateUser" or similar naming. I give meaning to each level of the hierarchy and document each, so they become like natural epic, feature and story levels.

It's extra work, but you basically end up with almost the same thing as if you had written a functional specification with use cases, just lighter weight.

If you have the features to do it in your agile tracking tool, you can use tags or categories and then produce a report of user stories that looks the same.

I remain convinced that agile and waterfall use almost the same basic tools but just in different ways.

I could go on how one can use formal project management Gantt charts to visualize sprints too.

Re: Split user stories ruthlessly and get value earlier

#24

Post by hal9000xp »

If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc.

These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done.

Please, do not point me at agile manifesto.

To me agile looks like totalitarian sect which constantly preaches flexibility and freedom while swiftly punishing anybody who ever dare to deviate from strict daily rituals and mantras.

Dry definitions in agile manifesto means nothing in real life. What's actually important is a context which created by people who adopted it.

Agile/scrum is biggest cargo cult I've ever seen in my life.

Re: Split user stories ruthlessly and get value earlier

#25

Post by fokinsean »

bonoetmalo wrote: post #16

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

Yup, recently moved to a smaller team. We have reduced standup to once a week and combined the other ceremonies into a single meeting, although we do give slack status' the other days. Even something this small has been a tremendous boost on my productivity.

I have been slowly suggesting we get rid of pointing all together, but I don't think that will be easily won :p

Re: Split user stories ruthlessly and get value earlier

#27

Post by sixdimensional »

hal9000xp wrote: post #24

If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile…

Actually, my opinion is that "agile" the way I most often see it is nothing more than a lighter weight variation of what we were already doing with SDLC. Time/cycles are compressed, documentation is not quite as structured, but the basic ideas are similar.

I agree the hype cycle distorts things too much. I think maybe your opinion is a bit too harsh, but - I would think to use whatever technique succeeds for the need and the team, whether more or less formal. So more power to you if the technique you prefer works.

Re: Split user stories ruthlessly and get value earlier

#28

Post by acdjuiamadfn »

hal9000xp wrote: post #24

If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile…

I cannot "upvote" you enough.

Re: Split user stories ruthlessly and get value earlier

#29

Post by sixdimensional »

acdjuiamadfn wrote: post #26

Okay, I read the article but why is this thing called "user story"?

A user story is basically a feature. It is higher level than a use case. Read Alistair Cockburn http://alistair.cockburn.us/Stop+confusing+use+cases+and+use....

Re: Split user stories ruthlessly and get value earlier

#30

Post by cormacrelf »

IshKebab wrote: post #19
bonoetmalo wrote: post #16

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.

There is some merit in at least trying to think about your users at every stage of the design. Methodically putting the user in every sentence refocuses your work on what makes the experience better for them. You are right that making it super repetitive makes you filter out the bits about user interaction when you read a long list.

User stories are mostly there to frame progress only in terms of things your project owner cares about. If you talk to non-tech people describing their experience of a product, they don't just reel off a list of nouns at you. They say 'you can click on the little thing and it wiggles'. So this is how you should be reporting to your non-tech boss.

Don't say 'I made /timesheet/:id redirect to /timesheet/:id/slug-of-sheet-name', say 'Users trying to get back to a timesheet can just type some of the name in their browser's URL bar and it will show up'. Definitely don't say the word 'slug'. They will thank you for it.

Post reply on HN