First sprint: Epics chosen instead of stories - should I re-estimate and when?

Question

I am trying out Scrum on a small, one-person project. During my first sprint, I realized that all of the stories I've chosen are really epics and should be broken down into much smaller pieces. The problem is that I've chosen too few story points, i.e. splitting would mean I have stories of .25, .1 story points of the original epics.

My instinct tells me to break down the epics after the sprint and re-estimate. Since this is the first sprint, it won't mess up historical data and let me start from a clean slate.

What do you think?

Answer 1

Before I reply I should point out that I really hate Scrum's estimation and velocity as it's traditionally done, so while this might give you some ideas, feel free to adapt your existing process accordingly.

The reason you're having to split "epics" into smaller stories and features is because they won't fit into the timebox of a sprint. There are only a few reasons to estimate and use timeboxes:

1. To engage stakeholders at regular intervals and get their feedback (those might be live users if you're actually releasing)
2. To get the trust of stakeholders, when they see that you can deliver what you said you would
3. To let people adjust scope based on history
4. To work out whether there are any elements of the problem you're solving that you might have misunderstandings about; different estimates can show this up.

Getting stakeholder feedback

You don't need to break things down to get feedback, if you're just focusing on doing something that will get stakeholders' feedback. Pick whichever thing you think you might need feedback on, then get something working and make it increasingly realistic within the timebox (and if you can get feedback early so much the better!) For instance, I hard-code a UI and show it to someone, then I get it working with a hash-map in memory, then I couple it to the persistence layers and thence the database (when the users are the stakeholder who is most able to give me feedback, anyway).

Getting stakeholder trust

If your stakeholders don't trust you, focus on delivering something valuable. You might need to split up your "epics" to do that, but this should be your focus, rather than "get something done within the sprint". If this is the case, pick small, safe things that you can do easily and quickly, because your relationship with the stakeholder is probably the biggest risk. After you've got their trust you can start trying the tricky stuff and getting their feedback.

Release planning and scope adjustment

If you want to adjust scope based on history, you can always do it with the original "epic" estimates. These are estimates, so they're likely to be wrong; you can't use a small sample of them to predict the future, so the scope adjustment is likely to be continuous and getting smaller as you approach release. (Ideally you're creating a Minimum Viable Product and releasing anyway so this point is moot).

Discovering uncertainty and misunderstanding

If you're using estimates to discover misunderstanding, you may still miss some. I suggest talking through examples of how the application might work instead, a la BDD.

Split them up as and when

Rather than focusing on having small enough stories for a sprint, you may find it more useful to focus on the reasons for having the sprint in the first place. Whatever you find yourself working on as a result, put it on the board, and life will be much easier, with shorter planning meetings.

It may help if you work out whether your "epics" are capabilities (provides the capability to trade copper, for instance) or features (one of potentially many concrete user interfaces that provide the capability). Splitting capabilities into features and having some wireframes sketched out before the sprint is IMO fine. After that, leave the dev team free to split up the stories as they see fit, based on the principles above. This will also help you get a self-organising team, and gives the team a clear focus for each timebox.

Craig Larman told me that the original reason for month-long sprints was because you could actually focus on small releases, with only the different MVPs being prioritised by the business. Feedback was available all the time, and how much could be achieved, and released, within that month was completely down to the dev team. I think this original vision of Scrum has been corrupted and is much missed.

If you're thinking of splitting your stories into tasks, please read this too.

Answer 2

Epics are always broken down to smaller pieces, before starting the sprint. Try to focus on delivering value (asked by the customer and important, too), so don't bother with your historical data. If the epic is the most important, break it down, and start working on it. After a couple sprints you'll have enough experience and data to establish velocity and use it.

Answer 3

TL; DR

Don't re-plan a completed sprint. Instead:

• terminate a failing sprint early and re-plan, or
• complete the sprint and use its data to adapt your estimation and planning process.

Treat data anomalies as such, and don't allow your Scrum framework to revolve around data points that aren't intended to be stringent mandates or infallible predictions.

Stories vs. Epics: Will They Fit?

During my first sprint, I realized that all of the stories I've chosen are really epics and should be broken down into much smaller pieces.

If it's your first sprint, you're still learning to estimate stories and to estimate your own capacity, so estimation errors are to be expected. However, in your particular case, you have two choices:

1. Your "epics" will fit within the sprint, and are therefore not really epics.
2. Your stories are too large to fit within the sprint, in which case you should return to Sprint Planning.

This is less about the story-point allocation than it is about deciding whether you've properly estimated your capacity for the sprint. If you think you may get enough stories done to meet your Sprint Goal then give it a try.

Scrum doesn't require perfection; it just requires that you inspect-and-adapt, and fail early when failure is inevitable. If you can deliver value this sprint, go for it—then use what you've learned this sprint to refine your estimation and planning process next time around. If no value can be derive during the sprint, then an early termination is certainly appropriate.

In-Sprint Decomposition

If you find yourself with a large story or epic on your hands, you can certainly break down the story into right-sized tasks on the Sprint Backlog. You only earn points for Product Backlog stories you complete by the end of the sprint, but decomposing a story into tasks has several benefits:

1. It gives you a better handle on the story, and often makes what to do next self-evident.
2. The decomposed task list will often give you a better idea of whether a story is completable within the sprint.

Scrum doesn't require that you complete all stories during the sprint, although that's obviously one of the goals. The real objective is to meet the Sprint Goal. If you decompose your stories properly in the Sprint Backlog, you may find that you can complete one or more stories that will meet the Sprint Goal even though you won't have completed the entire set of user stories. This would be a win!

Inspect and Adapt the Estimation Processes

My instinct tells me to break down the epics after the sprint and re-estimate. Since this is the first sprint, it won't mess up historical data and let me start from a clean slate.

Please don't do this. If you do, you're already heading down the road of treating velocity as a management target, rather than as a capacity planning tool or WIP limit.

By all means, review your Backlog Grooming and Sprint Planning process, and see where your estimation—and perhaps more importantly, your process for selecting an appropriate volume of stories off the Product Backlog—has gone wrong. This is a valuable use of the Sprint Retrospective process.

However, re-estimating or re-planning your sprint post facto is a waste of time—unless, of course, you've terminated your sprint early and returned to Sprint Planning. If that's not what you're doing, then keep your data points and move on with the process.

Handling Invalid Data Points and Outliers

At the end of a sprint, your Sprint Backlog, story estimates, and burn-down charts provide you with data to review your process. This data generally includes:

1. How much work you estimated that you had for the sprint.
2. How much work you completed during the sprint.
3. Whether your estimate was accurate.
4. Whether your volume of completed work, if it continues on the current track, will meet your project targets.

A story estimate is just a single data point with a couple of interpretations attached to it. If it's invalid data, you may choose to discard it. However, in your case it may very well be valid data, in the sense that it accurately reflects an underlying process problem that impacts the productivity of your current Scrum implementation. If that's the case, then keep the data point!

Estimation, by its very nature, requires more experience and a larger data set than you can gain in a single sprint. Unless you fail to fix your process over time, your single data point will eventually become a statistical outlier. Wikipedia says:

[S]ome data points will be further away from the sample mean than what is deemed reasonable. This can be due to incidental systematic error or flaws in the theory that generated an assumed family of probability distributions, or it may be that some observations are far from the center of the data. Outlier points can therefore indicate faulty data, erroneous procedures, or areas where a certain theory might not be valid. However, in large samples, a small number of outliers is to be expected (and not due to any anomalous condition).

In other words, a Sprint Planning session yields useful outliers when:

1. It indicates faulty data from your work-level estimates.
2. It indicates faulty procedures in the way stories were organized, (de)composed, or accepted into the sprint.
3. It indicates that your theories about how to implement Scrum on your current project may be flawed in some way, and should be carefully re-examined.

This is all valuable information for the inspect-and-adapt process. Learn from the experience, and then either discard the outliers or keep them for future analysis. In the end, your choice in the matter is just that, and doesn't really impact the efficacy of the overall framework as much as you may think.

Answer 4

Some really good points here - let me throw another cent or two.

First, you aren't actually doing Scrum if you are 1 person acting as Product Owner, Scrum Master, and the development team. To quote the Scrum guide, "the roles, artifacts, events, and rules are immutable." It's not a bad thing, I do agile development myself - taking a lot of pointers from Scrum and work on a two person team - on two platforms; so, really, it's just me for my platform.

The ideal size of a team, according to the assessment you can take at Scrum.org and implied by the guide is 6 +/- 3. According to the guide, when you drop below 3 developers you lose a diversity of knowledge, and when you get above 9 you increase the potential for sub-teams to form and inter-team communication to reduce.

Story points are only one method of estimating a level of effort required for a given story/task, which is a common practice, but not part of the Scrum framework. Finally, Scrum, as a framework is pretty loose and allows you to do whatever you need to do in order to get the work done...all the other stuff like stories and epics, story point estimation instead of hours, etc. is pretty much personal preference (according to the original founders).

Okay, technicalities aside, now to the actual meat of your question atomizing and estimating work.

It sounds like you have a backlog grooming issue - coupled with an estimation methodology issue. If you absolutely insist on using story points, one idea is to find the simplest story you can - that becomes 1 - it is a known baseline of complexity against which all other stories can be compared. Personally, I still prefer time-based estimates - but, totally up to you, just accept that chances are: (1) you will be wrong; (2) as your definition of done changes/improves, the level of effort for completing a level 1 story technically increases in relation to time and complexity, but you won't change the actual value; and (3) as development on a project continues, your estimates will increase in their incorrectness if not adjusted before each iteration.

This last point is one aspect of slipping into a "hyper-productive" state, which is really our inability to predict the evolution of our system and how the pieces eventually fit together and suddenly cause a ticket valued at 500 (estimated at 30 days) to collapse to something more like 100 (6 days).

Regarding how to build and groom a backlog - I tend to recommend starting high and atomizing to as close to one full day to get something from beginning to done. So, in my practice, this means a story/requirement estimate must be 8 hours or less including writing unit tests, coded, refactored, documented, and (optionally) reviewed by someone else (kinda hard to do on a one person operation). Which generally results in something akin to a WBS with "Build Fantabulous Product" at the top, which is then broken down, checked for reusable areas, etc. etc.

If you've overcommitted for the sprint and cannot complete all the items before the end of the time-box, then the SM-you needs to let the PO-you know, and then the PO-you needs to decide whether to abandon the sprint or not based on all the information received from external stakeholders and the rest of the team (because only the PO can abandon a sprint). Don't worry about the validity of the historical data - it's your first iteration, and you will need to do two or three more before having enough data points to even consider reviewing it for "scientific" improvement potential.

Last, let me go back to the Agile Manifesto and say, don't get bogged down in the processes (Scrum, XP, etc.) and the tools (stories, epics, story points, burn-down charts, etc.) - and focus on the interactions you have with your team (even if it's kind of a virtual team amongst your fellow Stackers), and feel free to abandon the plan (completing the sprint because you planned to and committed to the work) - that's perfectly acceptable - better to stop and pick a new direction than continue going in the wrong direction just because you said you would.

---

Scrum Guide http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf#zoom=100

Self Organization: Jeff Sutherland http://www.youtube.com/watch?v=M1q6b9JI2Wc

Scrum Framework: Lyssa Adkins http://www.youtube.com/watch?v=_BWbaZs1M_8

Scrum et al: Ken Schwaber http://www.youtube.com/watch?v=IyNPeTn8fpo

Agile Manifesto: http://agilemanifesto.org

Answer 5

Bear in mind that SCRUM teams should include 7 people +/-2, so you might find it awkward to plan, estimate, calculate velocity, be the SM etc on a one man team!