How to Estimate Big, Scary User Stories

Let’s talk about how to deal with stories that are hard to estimate. (If you’re interested in a broader discussion of Agile point-based estimation, check out this post over here.)

In every backlog I’ve estimated, I can recall running into a handful of stories for which I had no idea what point value to assign. I’d usually be using the following scale: 1, 2, 3, 5, 8, 13, 20, 40, 100. Most of my estimates would fall in the 1-13 range–nice and concise. I could feel a pattern coming together directing where every story would fit. Each one would take about the same amount of time to discuss. And then… Read more on How to Estimate Big, Scary User Stories…

Decomposing a Large-scale Design Project

My current project is very large, and we’ve been working on a process for decomposing features so that everything we design delivers value. This method also integrates tightly into Atomic’s agile software development practices, allowing both designers and developers to work on the same set of features simultaneously within continuous delivery cycles.

Project Background

During the project kick-off, we agreed to start by redesigning an existing website into a responsive mobile web app. We also needed to create a visual design system, incorporating a new brand direction that the client was introducing.

Our audience for this app was very large, and the demographic didn’t require a super modern aesthetic. Still, we did some brand exploration work to identify how the brand image and identity revealed itself in the existing and new visual design assets.

You want to learn as much as possible if there is an existing product and user base (analytics or research must be studied). With our UCD practices at Atomic, we want to base decisions on things we know (i.e. what the users/market are telling us, what the business needs are). Below I’ve outlined some basic steps to get you started. Read more on Decomposing a Large-scale Design Project…

Scouting Your User Stories

Most Agile teams plan work for an iteration by assigning points to user stories and selecting as many stories off the top of the priority queue as will fit within that team’s projected velocity for the iteration. In larger projects, the stories are often written and prioritized by a project manager or some other person who has a vested interest in the success of the iteration but is unlikely to be implementing the stories themselves.

When story point estimation goes well, the iteration planning meeting is a valuable communication tool that allows the development team and outside stakeholders to align expectations for the iteration. When stories are poorly estimated, however, things can go very badly. Developers are hurt when they get little recognition for hard work, and project managers suffer when what seemed to be a reasonable plan fails.

Read more on Scouting Your User Stories…

Moving Beyond Story Points, Iterations, and Burn Charts

If your team is not focused on delivering intermediate project milestones, they are missing what’s really of value. It’s easy to miss the forest for the trees if you’re only focusing on task-level points estimates and velocity tracking.

I’ve become frustrated with how burn charts focus on showing progress through an entire backlog and don’t clearly show the importance of incrementally delivering chunks of value.

Burn Charts Are Not Enough

Atomic has been experimenting with several approaches to help us focus, report against, and manage scope against intermediate milestones.

Read more on Moving Beyond Story Points, Iterations, and Burn Charts…

Breaking Down Epic Stories

A couple of years ago I wrote about how I was using Epic stories for early project estimations. Recently John Rusk posted a question in the comments:

I have a question about this: “We make no attempt to restrict that the total number of points from the resulting stories adds up to the previous estimate of the Epic”.


How do you find that affects your burn charts? In particular, imagine you are half way through a project. All the epics up to that point in the project have been “expanded” into smaller user stories. But the epics after that point have not yet been expanded. Imagine also that, when expanding an epics, the total number of points in the small stories is typically greater than the total of the original epic.


This would mean that past work has reasonably accurate numbers of points associated with it, but that future work, still in epic form, is underestimated. (Since, when you decompose the future work, its point value will typically go up, so therefore its current point value is too low).


If this happens, it may skew your burn charts and make you think you’re closer to finishing than you really are.


However, from your description of your success with this approach, I take it that this problem doesn’t actually affect you. I have used a similar approach myself but, being concerned about the above problem, I have always taken care to preserve the same total point value when breaking down the epics. Hence my interest in hearing how you have tackled, or avoided, the same problem.

I am using Epics to get a very rough estimate of the size of the project, without having to spend an inordinate amount of time wading through the details at the beginning of the project (at the point of maximum ignorance as Carl is fond of saying).


Read more on Breaking Down Epic Stories…