How about splitting all user stories until they’re likely to take three or fewer days to complete? Let’s forget story points. It’s worth a try. If it doesn’t work, you can try something different.

Dev: Why?

Breaking larger problems down into smaller problems is a good practice. It is like DRY or the single responsibility principle. Plus, you’ll never worry about story points again.

Dev: But what if I get interrupted! How about meetings? We’re putting out fires every day!

Assume minimal interruptions (and multitasking) when scoping the story. If it takes longer because of interruptions, then that will be a cue to the team to make those interruptions go away. We’ll commit to removing those blockers, as they will inevitably come up. Good job! You found a blocker.

Dev: This will lead to shoddy work. We’ll rush it!

Don’t compromise on quality. Just make the problem smaller. My guess is that this will improve quality. And if it doesn’t, we’ll change how we work.

Dev: What about story points? What about estimates?

Focus on building the story-splitting discipline. That will trigger the “conversations” (one benefit ascribed to estimates). You’ve already got a small story (another benefit, as you’re supposed to “ask if you can break up the big stories”). When estimates/forecasts are important, there are other ways to achieve that.

Dev: Is this like that #NoEstimates thing I’ve read about?

No. It is #SmallUserStories and losing the story point estimation.

Dev: But if we use “days”, people will think we’ll deliver in days!

Yes. T-shirt sizes and the Fibonacci series are wonderfully obtuse to the business. Days are scary. What if it takes longer? What if someone communicates a deadline? Don’t invent practices based purely on the expected dysfunctional behaviors of others. Days are nice and human. They correspond with our sleep cycle. Assume a functional situation.

Dev: I read this quote, and now I’m confused. Will this happen?

If the team’s ability improves to the point that what used to take two days now takes only one, unimplemented stories with a “2 day” estimate should be changed to “1 day”. This problem largely goes away with points.No. Because we don’t care if it takes one day or three days. And we’re not trying some useless effort to generate “Agile metrics” to show a manager we’re going faster. That’s either obvious or it isn’t. We’re in the results game, and not the velocity game. We should measure progress towards creating positive outcomes from the business. If we need to measure anything about the flow of work (as opposed to the outcomes we create, which of course we measure), we’ll measure cycle time, lead time, or cumulative flow.

Dev: But we pair. What happens then?

Cool. Sounds like it can still take three or less days.

Dev: Do we still get “credit” for the points?

Credit for what? Who in your business has set up this perverse game that gives you credit for weird fictional story points? And who punishes and DIScredits you? Don’t worry about getting faux-credit. Let’s focus on creating results for our customers and take credit for that.

Dev: Oh geez. That will be too many stories in Jira. What a pain.

Then use a physical board. It takes 60s to write an index card with some acceptance criteria. Don’t use tools that slow you down.

Dev: How many stories should we do each sprint? We used to add up the points.

Two (or three) per week sounds about right. Give it a try and we can adjust. If you have some slack, fix something that is bugging you that makes your work life less cool/productive/fun or working on a personal project.

Dev: But what if one overlaps the end of a sprint?

Good question. Maybe end the sprint a day or two later/earlier? Why are we doing sprints anyway?

Dev: But this story involves UX. They need another task, right?

Sounds more like a three-dayer. Pair with UX on day one. Maybe test some prototypes with a customer that afternoon. Is that difficult? Work on making that easier.

Dev: These small stories may not be independently releasable!

That’s a great point, and I’m psyched you’re referencing INVEST. This touches “I” ndependent (of all others), and “S” mall (so as to fit within an iteration). I sincerely believe there is some as-of-yet named thing that is bigger than a task, but is smaller than a user story. It can be demoed. It includes tests, and meets acceptance criteria. It can be released in production behind a feature-flag without failing tests. It is ready to communicate with other services when the time comes. Anyway … point taken, but slice these thing-stories to under four days if possible.

Dev: Nothing we do takes under four days!

OK. That’s a problem, and it is a big one. Why? It is not like you’re slacking. So … either you’re not factoring in your interruptions (see above), your tools are lacking, your stories are too big, or you are constantly juggling multiple stories because everything is blocked somehow.

Dev: What if I can’t break this one story down to under three days?

Don’t worry about it. This is a guideline and not a rule. Some things are big and defy all efforts at decomposition. At least this will send up the warning flare.

Dev: But what if it ends up taking longer than three days?

Don’t worry about it. We learn and adapt. And by all means “run with it” if you’ve had a breakthrough and want to tear it apart and start over.

Biz Person: People will always take three days! This will get abused.

“Abuse” is a big word. So is “game the system”. Maybe, just maybe, the problem is the system? Does your team look forward to showing up at work? Are you asking them to be professional firefighters? Are they tasked with things that deliver validate-able value to the business? Have you sucked the life out of their work with mind-numbing ritual, status checks, and whip-cracking? My observation is that people settle into gaming the system when they have no sense of impact and momentum. What would it take for someone to excitedly finish one story and pull the next one off the queue?

Biz Person: But, but … there’s a big difference between one and three days! If I add up all the stories I might get 30 days, or 90 days!

Don’t worry about it. You think that will make a difference, but it won’t. Figure 2.5d avg. and be surprised.

Dev: This seems like some stupid management trick to make us work faster.

No one is saying work faster. Just work on smaller stories. Actually, this “trick” is sort of pro-developer. First, I’ll never bother you with storypoint estimation again. Second, I’ll commit to removing the blockers that make 1–3d turnaround difficult, and get in your way. Faster isn’t the goal. Flow and delivering continuous (validated) value is the goal. Smaller batches work.

Dev: I’m not persuaded.

Come on. I know the team cares about craftsmanship. You’ve probably even told someone to break up classes and functions. That’s the discipline I’m talking about. The problem is that stories become the communication layer between the team and “the business”. That inspires all sorts of defensiveness and stress because, let’s face it, businesses often abuse them. You’re measured by this these things (which is stupid). They form the basis for velocity measurements (more stupid). Put all of that aside. This is how we break down our work to make our product great.