As a developer, we have the toughest role throughout the project lifecycle: Estimating our work. The business (typically) puts so much at stake onto the developer for elaboration and understanding about the time and schedule of a project. It’s a tough life for a developer.
But fear not! There are resources to help you estimate your stories.
One great article we recently found was by Nicole Rauch, she states when when estimating a story you need to take into account several things:
- Complexity: Consider the size of the story.
- Risk: Consider the teams inexperience with developing this story.
- Implementation: Consider the implementation factors.
- Deployment: Consider the deployment requirements.
- Interdependencies: Consider other outside issues.
We would add that developers should begin (over time) to develop a baseline for estimating sizes of stories. Use examples of past stories that can help developers understand relative sizes. Ask questions like: “How does this story compare to X-story we did before? Bigger or smaller?”
Now, the question really is whether you use points or hours for estimation. Mike Cohn suggests to use points for product backlogs, and hours for tasks.
Bottom line? Agile estimation is an art form that grows better over time. As your team matures and developers a solid baseline for estimating work it can produce a consistant cadence or velocity that is (somewhat) predictable for the long run, but not great at estimating short durations.
Find out more:
- Agile Estimation 2.0 Game
- Manoj Vadakkan on taking small steps in acquiring better Agile estimation over time.
- Scott Ambler has put together an introduction to User Stories. One of the best.
- Below is a workshop deck for Agile Estimation and Planning with User Stories by Peter Saddington