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

91–98 of 98 posts

Re: Split user stories ruthlessly and get value earlier

#91

Post by scarface74 »

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…

Would you rather be in a situation that before any real work gets done you have to have a "project charter", 3 months worth of requirement gathering, three months worth of development and user testing and find out at the end that your delivered product is completely unusable by the people you were developing for?

"Buzzwords" create a ubiquitous language (a Domain Driven Design buzzword). I can change companies and if they are using those "buzzwords", I know what they mean.

Re: Split user stories ruthlessly and get value earlier

#92

Post by philliphaydon »

talldan wrote: post #45
IshKebab wrote: post #19

Earlier quoted context omitted.

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.

The biggest problem with user stories for me, is that the amount of text often ends up making the board view in JIRA hard to read!

People use jira?

Re: Split user stories ruthlessly and get value earlier

#93

Post by dragonwriter »

scarface74 wrote: post #91
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…

Would you rather be in a situation that before any real work gets done you have to have a "project charter", 3 months worth of requirement gathering, three months worth of development and user testing and find out at the end that your delivered product is completely unusable by the people you were developing for? "Buzzwords" create a ubiquitous language (a Domain Driven Design buzzword). I can change companies and if…

> "Buzzwords" create a ubiquitous language

No, that's jargon. Buzzwords are distinguished from jargon by being language that has become semantically ambiguous (possibly even semantically null) through pervasive inconsistent use, particularly in marketing.

Re: Split user stories ruthlessly and get value earlier

#94

Post by Zigurd »

UK-AL wrote: post #58
Zigurd wrote: post #3

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

The hard part for agile projects is that you only loosely know what is the desired end result. Specs should and will change.

That's the good part about agile. The bad part is that the idea of a "story" goes a bit too far in trying to make specification creation accessible. Decomposing stories into smaller pieces is a solution that's palatable to many because it avoids the hard work: Gaining more domain knowledge, and developing critical thinking.

Re: Split user stories ruthlessly and get value earlier

#95

Post by another-dave »

zero_shift wrote: post #86
another-dave wrote: post #37

Earlier quoted context omitted.

The point of the "narrative statement" is to show what value implementing a story will bring to help bring a relative priority order to things. Otherwise people keep championing their pet features, without focusing on _what's the point_ of this feature. "As a user, I want to be able to find the full version number of the product to make it easier to get help when raising support requests". This is now something we ca…

Why not just write, "We want to add the software version number to the dialog. We think they will then cite this when they raise tickets" ? At least in this form, you can expand on the context and justify it in depth. Also, user stories often phrase the context as a given when it's really not. In your example, it's an implicit premise that a version number may help. In mine, the writer admits scepticism and therefore…

IMO, the format is meant to do two things:

* By having a premise, it forces you to question its validity up front (before any development work is done), getting rid of ambiguities early and having a shared understanding between business and technical team members (rather than the developer implementing what they think is a better solution, the product owner being unhappy with the outcome & only finding this out at the end).

* Using the format of "As a , I want to , so that I can " forces you to think about what user (customer/website editor/back office) gets what specific value (faster/cheaper/less error prone) from implementing some feature. By following the same pattern it makes it easier to compare unrelated areas.

I don't think the format is sacrosanct, but it's like any constraint you put on yourself (e.g. coding conventions) — if you find it hard to make a story work in that format, it's an indication that it may not be properly understood it really bringing value.

Re: Split user stories ruthlessly and get value earlier

#96

Post by meheleventyone »

maxxxxx wrote: post #82
jacalata wrote: post #80

Earlier quoted context omitted.

A significant part of the agile process is that meeting the spec isn't the goal, being accepted by the customer is. Your description sounds like there were no sprint reviews to get customer feedback, or it was ignored. So you're arguing that a significant problem with agile is that if you skip a fundamental piece, it results in bad outcomes?

A few problems with the customer feedback thing: - the person assigned to you as voice of customer does not use the product - the person doesn't have time to engage with the dev team - the person doesn't care Over the years I have seen exactly one product owner who could give useful feedback. All the others in the end had no idea what they were after.

Hence the growth in people caring about things like UX design, user testing and releasing early to get feedback.

Re: Split user stories ruthlessly and get value earlier

#98

Post by crdoconnor »

tootie wrote: post #38
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…

Anyone who traffics in buzzwords without adding value is the problem. Scrum is fantastic when you understand the why of its process instead of just following the rules. If you schedule scrums and sprint planning, then accept ungroomed stories, change priorities, deliver without testing, then you are doing it wrong. Really disciplined and experienced teams can follow the intent without the process, but more often than…

If it truly worked you should be able to just follow the process.

IME tech debt gets worse under "scrum done right" and velocity is a bullshit measure. Those two things alone are enough to reject it.

It's a shame because scrum gets, like, 70% right.

Post reply on HN