
Split user stories ruthlessly and get value earlier - mikeborozdin
http://mikeborozdin.com/post/split-user-stories-get-value-early/
======
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.

~~~
UK-AL
You haven't seen cargo cult until you've worked in an organisation with a pmo,
and tranditional project management.

I had to literally write a 5 page business case for relatively small features
that takes more than 5 days. You then had to get it approved by the pmo board.
These people have no product management skills either.

Once it's a approved I have to write a full plan and schedule.

Companies like this exist.

This is what agile was a reaction to.

~~~
Angostura
This can actually be very useful as it insulates your dev team from some VP
wandering across and demanding a pet feature be implemented. The VP has to
negotiate the PMO board first

~~~
UK-AL
A product owner in agile can do exactly the same without the overhead.

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

~~~
joncp
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.

~~~
stult
Agile doesn't work with cars because you can't deliver value incrementally by
designing additional features. Producing a brake pad this week doesn't help if
the chassis is still unfinished. Similarly having the entire car except the
brake pads complete doesn't deliver any value. It's all or nothing.

~~~
Huggernaut
Not sure I totally agree that it can't be done. I have no idea whether it's at
all realistic/sensible/pragmatic to create a car via agile but taking your
brake pad example it would seem very alright to have a set of stories such as:

"As a driver, I can stop the car at a reasonable pace" \- ok, maybe you get
some awful brake pads to begin with (or maybe if you are cheeky you just
say...well, air resistance does that!)

"As a driver, when the car is travelling fast, I can stop the car extremely
quickly" \- ok so now we probably need some reasonable brake pads.

"As a driver, I don't need to replace the stopping mechanism all the time" \-
ok so maybe now we need to make sure the brake pads fitted are of a certain
quality.

I think you can see where this is going. Sure the car probably needs brake
pads...but assuming you didn't know much about cars (something agile is suited
for), at each stage you could decide you need to do something different for
the stopping mechanism. Additionally, many of the qualities of the brake pads
demonstrate that things are not "all or nothing" necessarily.

------
talldan
> You read articles that say it should be possible to complete a user story
> within a single sprint, ideally within a few days. That’s entirely accurate.

I'm surprised by that, as I tend to break down stories even smaller, to the
point where they can be completed in a day or two. Anything that takes longer
I consider risky and potentially a rogue story that could end up eating a lot
of time.

Smaller stories are easier to manage, easier to refactor, it's much easier to
review the resulting code and they usually have less complexity. I think it's
sometimes easier to clear blockers with smaller stories as well.

Downsides are that it can be harder to get an overall view on the progress
being made during a sprint, and sometimes tasks can have more dependencies or
it can be harder to work on things in parallel. It also takes more time to
prioritise the backlog.

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

~~~
talldan
I imagine when something about the project changes, it takes a really long
time to rewrite all those stories? Or you end up never re-assessing because it
takes too long.

~~~
maaaats
We often end up reusing the stories for completely different stuff, as they
then have already been approved so we can skip some of the boilerplate, haha.

------
Zigurd
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, but it isn't a substitute
for domain knowledge and systems analysis training.

~~~
UK-AL
The hard part for agile projects is that you only loosely know what is the
desired end result.

Specs should and will change.

~~~
Zigurd
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.

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

~~~
IshKebab
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.

~~~
talldan
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!

~~~
joshwa
Number one thing I do-- titles need to be scannable:

Admin :: Roles :: Multiple Roles)

And the "story" part goes in the body:

"As an adminstrator I assign multiple roles to users so they have access to
all the parts (and only those parts) of the application they need to do their
job."

..with additional context, exceptions, rules, examples, etc, in the body.

------
perlgeek
Following 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/](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.

------
andrewprock
"As a developer, I want to be able to log time spent on projects. So that the
company could analyse [sic] time spent on different projects."

This user story is utterly absurd.

In this case, the "user" is actually the company, not the developer. The
developer usually wants to provide business value by adding new features, or
fixing bugs. And this is a feature, but it's not a feature for the developer.
It's a feature for the company.

The fact that it got broken down into manual data entry features like:

"Users (read developers) select a project and enter hours spent for each day"

Makes me question whether the users were involved in making the stories at
all.

This article feels like an illustration of what is wrong with Big-A Agile, not
an exemplar of how to do it right.

------
SoulMan
I love the discussion happening here. I am into projects which "follow agile
model" more than last 5 years, however every time I bring up such questions to
folks who are die hard fan of these buzz words (mostly non-engineers), I am
threatened to be sent to days long Agile/SAFe training again and looked down
upon blaming I have "Old school waterfall mentality".

I am not saying Agile does not have any value at all. I think it helps middle
management (top management only see some high level slides) get some numbers
to measure how much work has been done and how much time is remaining to
complete the features in the road map (epic progress). On the flip side
everyone else forced to make those numbers good (either by working on weekend
or taking short-cut with tech debts or in worst case compromise quality). This
becomes obvious when managers set rules like - 90% of the stories must be
completed at the end of two weeks sprint (if there are less than 10 stories,
you have to close all of them). I see all stories coming to code review ,
merged, deployed , tested & closed on the last day of the sprint. Even if
engineers believe do not believe its going too fast (superficial review, lack
of manual testing) scrum master end up make it happen as his job is to make
sure "sprint commitments" are met.

Now enter the world of SAFe. You plan for 3 to 5 months and can't do anything
different in this time period (Where is the agility ?). You can't prioritize
tech debts that you carried when you took shortcuts earlier to deliver MVP as
"things are going alright". Hence, no iteration , only look ahead deliver more
features. Spend a week on just planning and trying to accommodate feature
based on "High level estimate" which is usually 50% accurate because you have
not broken down to stories yet or has not done any experiments to check if
some technology or recipe works or not. In addition to this you have hours of
grooming, standups planning, retro , review in each up coming sprint involving
the whole team.

I think every time you fit a process which may have worked in auto-mobile
industry to software industry trying to "get more value " (lean is a new
thing) you cease to be an innovative company.

~~~
ju-st
Your company isn't doing Scrum at all. Your management is only using agile
vocabulary and that's where the parallels end. And that's how Scrum gets a bad
name.

~~~
doseofreality
This is the inevitable and unwinnable argument in any thread that dares to
question the value of Scrum.

~~~
ju-st
Sorry, I have clarified my point with an example in another post:
[https://news.ycombinator.com/item?id=15004260](https://news.ycombinator.com/item?id=15004260)

------
Spooky23
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 needs to be in the
approval process to throw back work when all of the necessary interactions
aren't captured.

~~~
ethbro
_> 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

------
adrianratnapala
I approve of this, but I come at it from an I-just-want-to-be-an-engineer
point of view.

When looking for velocity, the first thing to optimise is the feature list.
Too often the idea of doing something useful quick and dirty devolves into
writing bad code that looks like it covers a feature set until you scratch the
surface and find the whole thing is made of bugs.

But if you reduce the feature set (that's the first kind of dirty) then you
can build a system that really does what it says on the tin. And the second
kind of dirty (code), deosn't matter so much, because in a smaller system the
total technical debt is less.

------
gtramont
Reminded me of Paul Hammant's posts:

\- [https://paulhammant.com/2012/04/24/call-to-arms-average-
stor...](https://paulhammant.com/2012/04/24/call-to-arms-average-story-sizes-
of-one-day/)

\- [https://paulhammant.com/2012/11/12/smaller-
stories/](https://paulhammant.com/2012/11/12/smaller-stories/)

~~~
gtramont
And Mike Cohn's SPIDR tips for splitting stories:

\-
[https://pbs.twimg.com/media/DBuzze5XsAA2Zbt.jpg:large](https://pbs.twimg.com/media/DBuzze5XsAA2Zbt.jpg:large)

------
tootie
I generally advocate this approach, but there is a limit. Each new story is a
context switch for everyone involved. It's easy for a product manager to lose
track of the holistic POV if they are tracking too many stories. The dev has
to stop and start or worse yet, split very tightly coupled work among more
than one dev.

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

~~~
zo1
Jira is just a ticketing system with a lot of fancy (and optional) features
built on-top of it. Or are you asking specifically about the Jira Agile
feature?

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

~~~
sixdimensional
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...](http://alistair.cockburn.us/Stop+confusing+use+cases+and+user+stories).

------
asdfpoiu10
Looks like someones been drinking too much of the agile kool-aid...

