Story point definition

[gabeweaver]

We need to come to a consensus on what represents 1 story point. What does it measure? How do we want to define it in a consistent manner across all projects?

Here is what we are trying to accomplish with story points:

• Something we use consistently across projects as a unit of measure for how complex, difficult, etc. we think a story is. The goal is to establish a consistent way of handling story points so that over the course of a project/projects, we can establish a velocity that represents how long we believe a story will take to complete. This means that as projects progress, some stories might become less complex. The point here is to adopt a standard definition of what a story point is. Only then will we be able to work towards learning how we make estimates and understanding more about what it takes to make good estimates.

[shawjb]

One question to ask is how are story points assigned? In the past on larger projects we did a group vote. Other times it's just been whomever has the ticket assigned.

[ryankeairns]

Another consideration would be how to handle the 1-2 hours type of tasks (0 too short, 1 too long). These are very common on smaller projects and maintenance type tasks. Perhaps using a point as a half day block of time and scheduling all of our work in this manner as well.

[tpalmer]

story points != hours or days story points = complexity points

That being said - if we want to have some kind of consistency across projects, we should establish a baseline story, and then measure effort of future stories off of it. A story point estimate is an estimate of the amount of effort a story will take to complete; the whole point of 'story points' is to abstract out determining hours to complete something.

If it would be easier to conceptualize, we could use terms like 'small', 'medium', 'large', 'x-large'... the representation is irrelevant, as long as there is consistency when estimating.

[gabeweaver]

https://www.pivotaltracker.com/help/gettingstarted watch the "concepts" video. Pivotal tracker's default story estimation scheme is based on complexity where Easy = 1, Medium = 2, Hard = 4, break it down = 8. I say we just go with this...

[tristanoneil]

Great video. We should make all of our clients and any new developers watch this before proceeding to work on a project, very insightful. Maybe if our process varies from this at all it might even be helpful if we create our own process video but what I just watched seems like it falls inline with how we work. I like the idea of complexity points over time based points. I think also we need to be more diligent about admitting when we need to break down a story into multiple stories, I think this is when we run into the most trouble while estimating.