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:
- Your "epics" will fit within the sprint, and are therefore not really epics.
- 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:
- It gives you a better handle on the story, and often makes what to do next self-evident.
- 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:
- How much work you estimated that you had for the sprint.
- How much work you completed during the sprint.
- Whether your estimate was accurate.
- 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:
- It indicates faulty data from your work-level estimates.
- It indicates faulty procedures in the way stories were organized, (de)composed, or accepted into the sprint.
- 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.