How we estimate user stories
All user stories in the backlog must be estimated with points that represent effort. It’s an iron-clad rule that product management is not allowed to put a story into the backlog before getting an estimate for it.
New projects are kicked off with inception meetings where an initial estimated backlog is produced, covering at least 2 to 3 months worth of work. (aka “storycarding sessions”).
Throughout the rest of the project timeline, product managers and their business analysts will meet with members of the engineering team on as-needed basis to gather estimates for new or revised stories. They need to do this in order to properly maintain the team’s backlog. It’s up to the team whether it gets together as a whole to help estimate new stories or delegates that work to a representative.
THE POINT SCALE
I’ve found that this scale is easy to explain and easy for developers to get good at using. It also ensures that points reflect effort instead of time estimates. Do not give any user stories 0 points on the basis of it being easy. We have complex production systems. Nothing is that easy.
1 Point
I understand exactly what needs to be done, and exactly how to do it.
2 Points
I understand exactly what needs to be done, but I’m going to have to do a little bit of thinking or experimentation to figure out how to do it.
4 Points
I mostly understand what needs to be done, and unless I’m way off base, I kind of understand how I would do it. (But there is not enough uncertainty here to reject the story altogether as invalid.)
ONLY USER STORIES GET POINT ESTIMATES
Bugs (defects, specifically) and technical tasks are always designated as 0 points. However, “bugs” that actually represent a change in stakeholder’s requirements are classified as feature requests and given points when they are added to the backlog.
It is the responsibility of the product manager and engineers to work together to make sure that bugs that are change requests in disguise are classified appropriately.
When we talk about defects we are talking about correctness of software as per its specification. Since product managers do not give engineers one-hundred percent formal and perfect specifications, there will always be issues that crop up around developer judgment calls that product managers ended up disagreeing with. Within reason, it is expected that you talk with product managers or business analysts whenever you need clarification on details of a user story
HOW WILL I GET CREDIT FOR MY TIME IF I END UP WORKING ON LOTS OF ZERO POINT STORIES?
First of all, remember that you are a professional engineer, not a laborer. Points are not (and were never intended to be) a unit of time used to measure individual productivity or output. Velocity (derived from number of points completed during a timebox) is a team metric and does not apply to an individual.
The only valuable reason to track points and measure team velocity is so that product managers are able to predict the timing of future milestones with a relatively high degree of precision.
By definition, if you are working on mostly zero-point stories, then you are not delivering business value. That situation is supposed to be painful and intolerable to everyone involved, both product managers and engineers. It can never just be a normal state of affairs like it currently is on some of our teams.
A team that is consistently failing to deliver business value (as indicated by diminished or near-zero team velocity) needs help from management. The need for help should be obvious to everyone involved. The way we’ve been doing things in the past, and how many Scrum teams do their points estimation, makes it too easy for the business stakeholders and product owners to de-prioritize paying down technical debt, to the detriment of everyone involved.
