Stories, tasks, and iterations in practice. What am I actually looking at?

[Rob Whittaker]

I've been reading Extreme Programming Installed this month. The book describes a clear hierarchy:

• Stories are what the customer wants
• Tasks are how developers deliver them
• Iterations bundle tasks into short cycles
• Releases ship value

In practice, our cards may not match any of those.

We use Trello with one-week iterations. Our cards are granular. One per branch in a Rails controller action. A card for the success path, a card for the failure path. Most cards take 2-3 days to complete.

By the book's definitions, these feel like tasks. But we don't have anything above them. No parent story says, "As a user, I can do X." A customer request lands in a backlog. We discuss it in planning. Cards appear on the board. Time pressure means we skip the breakdown the book describes.

So my questions:

1. In the book, stories get broken into tasks during iteration planning. If our cards are already at the task level, what are we missing by not having the story layer above them?
2. A 2-3 day card in a 1-week iteration means we complete 2-3 cards per person per week. Is that a sign the cards are too big for tasks, or too small for stories?
3. How has this hierarchy changed in 25 years? The book assumes rare releases and a formal planning game. We deploy on every merge and plan as we go. Does the story/task distinction still matter, or has it collapsed?

[Mark Kirschstein]

I'll preface this with that I haven't read that book, but I'll chime in with my opinions anyway.

1. One anti pattern is that people use the names epic/story/task and translate those into hierarchical buckets and little else. The purpose of the user story was that it is a description of the user's problem or the goal they're trying to achieve, and then the developer went and spoke to that user armed with this context to learn more about what they were doing. The aim was to build better software by truly understanding the user's needs, not building something that we thought they needed based on long lists of features. Things were broken down into tasks to manage larger more complex requirements. Mostly, people slap a tag on a ticketing system or use some flaccid as a User I want a feature so that I can use a feature language and call it a day.

2. You can try splitting them further and seeing what this results in, experiment. I do note "per person" here though, but you didn't ask about pairing...

3. I think we have tended more towards JIT approaches and faster cadences than the book presumes. I think a lot of the material that was written when 2 year+ projects were the deliverable size thought they were already on the extreme size by suggesting increments in months or weeks.

[Rob Whittaker]

Thanks, Mark. Three things jumped out.

On stories as conversations: you're right that the formula ("As a user I want...") misses the point. The book frames the story card as a reminder to have a conversation, not a spec. We skip that step. A client request goes into Trello and becomes cards. No one sits down to understand the problem behind it. The hierarchy question I asked was a proxy for: Are we losing that conversation?

On pairing: good catch. We pair on client projects. The "per person" framing was sloppy. The question is whether 2-3 day cards leave enough room for the pair to:

• Finish
• Reflect
• Pick up the next thing

All inside a one-week iteration. Or whether the cards should be smaller to tighten the feedback loop.

On cadence: that reframing helps. The book treats two-week iterations as radical. We deploy on every merge. The planning game it describes assumes you batch decisions. We make them as we go. So the story/task split may have collapsed into something closer to "what are we solving next?" without the formal hierarchy.

What does your team use instead of stories? Do you still break work down into layers, or has it flattened?

[Murray Tait]

If we are looking at original intent by looking back at Extreme Programming Installed, we should also consult that https://wiki.c2.com/?UserStory which is where most of these ideas were discussed and first written down. 

It's a bit dated with respect to the methodologies used as comparisons, but this discussion here has echos with that discussion back then (https://wiki.c2.com/?UserStoryAndUseCaseDiscussion)

--
You received this message because you are subscribed to the Google Groups "xp-manchester" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xp-mancheste...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/xp-manchester/0b9d2029-9eea-4a13-95c8-61084dc62544n%40googlegroups.com.

[Paul D'Ambra]

since i'm in a silly mood

a young woman goes to a priest and says "Father, when I pray I tell god what i'd like to be better in the world. they're not things I can do though, is it really praying?"
the priest says "yes"
the next day an old man says "Father, when I pray I ask god to look after my grandchildren. it seems selfish to not ask about other children. is it really praying?"
the priest says "yes"
the next day a young man says "Father when I pray I tell god what i hope for in my future. it helps me think about how to achieve my goals. but is it really praying?"
the priest says "yes"
the next day another man says "Father, We skip that step. A client request goes into Trello and becomes cards. No one sits down to understand the problem behind it.. is it really praying"
the priest says "no"

you're making something because you believe it is useful to at least one person
the process you follow to do that is gigantically unimportant - except where it _locally_ helps you all get better at doing that. just don't sweat the details, sweat the goal

the only useful bit in all of user stories is "placeholder for a conversation"
the framework you follow doesn't mean anything if you're not actually talking to the customer
that might mean email surveys or a user interview or analtyics or working at the desk next to the customer or standing outside a coffee shop and showing it to random people
it might mean building a fake UI for a complex task they can't describe but you can capture what they really do

etc etc

most ideas (like user stories) are only really useful when they're fresh because they help jolt people out of their existing behaviour
user stories now are not fresh, they have enough bad implementations in the wild that people come to a team with preconceived notions of how to do them and it gets in the way of the important thing

Your original question

> Does the story/task distinction still matter, or has it collapsed?

I think it never mattered in any global sense even if it mattered in a particular team or to a particular person

The goal (imho) is to make useful things at about the speed your users can cope with.

Breaking things down into tasks is a great way ime of being able to see the flow of work and have that hide the flow of value

P

--

You received this message because you are subscribed to the Google Groups "xp-manchester" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xp-mancheste...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/xp-manchester/9e7af5a5-34c7-4447-a7d0-784a21c793ban%40googlegroups.com.

[Rob Whittaker]

Murray, thanks for the C2 links. Reading the original UserStory page drives the point home. The card is a prompt to talk. Not a spec, not a ticket, not a Trello card. A reminder that you don't know enough yet.

Paul, that parable landed. The priest's "no" is the answer to my original question. If we skip the conversation, the rest of the process is theatre.

What strikes me is how all three of you converged on the same point from different angles:

• Mark: The formula ("As a user I want...") replaced the conversation it set out to start
• Murray: The original C2 wiki defined stories as placeholders, not artefacts
• Paul: Breaking work into tasks shows the flow of work and hides the flow of value

⠀

That last line is the one I'll carry forward. We track cards. We move them across columns. We measure velocity. None of that tells us whether the thing we built was useful.

Does the story/task distinction still matter? Wrong question. The distinction is between teams that talk to their users and teams that don't.