Thoughts about Story Points
Story points are arbitrary unit of measurement for a task complexity. There are different methods used in practice to estimate how many story points a task is worth. Usually, all team members give their estimates, they discuss it, then they agree on a number. Using that number, and the velocity, you can estimate the time it’ll take this team to finish a specific task. Note, it is an iterative and adaptive process. In other words, it gets better and more accurate over time.
#1 — Story points need to be unified
I believe that the concept of having a unit of measurement for task complexities is absolutely essential. However, I don’t think that story points is applied in a right way. For example, If I can ask you to measure the weight of a laptop, you would bring a scale, then tell me the weight in a unit such as pounds or kilograms. If I asked your friend to weigh it, he should give me the same weight — given that the scales are accurate. Try doing that with sprint tasks.
I think that we should have a unified scale to use and then the only variable would be the velocity. It makes sense that different teams have different velocities depending on their experience and skill level. But it doesn’t make sense that the same task can weigh 20 story points within one team and weigh 5 points within another team.
Is this hard to accomplish? Sure it is. Maybe we should have experts give their estimates. Then, all teams use these estimates. Maybe we should have a portal where we write tasks then all developers in the world give their estimates and we use the mean value. Maybe tasks should be written in a way that doesn’t leave a chance for wrong estimation of story points. Remember, I am not talking about time estimates at all in here.
#2 — Estimating unknowns is close to impossible.
It isn’t rare to have a task that is simply “research blah“, or “investigate issue xyz“. There are so many unknowns in such tasks. Is story points the right unit here? Can a pounds scale give you unknown value? What does that mean? Can scrum accept unknown value for story points? If so, how does that affect the time estimates?
#3 — Story points for non-functional requirements.
Performance, scalability, reliability, security, usability are usually categorized as non-functional requirements. This usually means that it isn’t explicitly mentioned in the task description, but a developer needs to implement them. How do we measure these non-functional requirements in story points? What’s the complexity of good performance? or highly scalable script?
These are some of my thoughts/questions about story points. Please, share your thoughts, ideas, answers, questions, explanations, experiences with story points.
posted: 09 October 21
under: Agile Methodologies, Scrum
There also comes the question of do you include testing time in the weighting or do you build separate tasks? SCRUM preaches a unified team so without weighting the task with testing time, you’ll never have an accurate velocity.
Most companies (none in Blacksburg/Roanoke, except Vitech) don’t have highly technical QA Engineers. The tester needs to understand the task from a development point-of-view before they can accurately apply a story point estimate. Then, and only then, do story points work.
I have to tell you Khaled, I disagree.
Story point assignment comes before we know details. Story points and velocity are tools for the business leaders to use to estimate how long (in sprints) before particular features are complete. They don’t provide perfectly accurate estimates, but as with all things agile the goal is to get better and better over time.
But really, I think the key is that these are assigned without knowing all the details. To use your own metaphor, I would say these are done without having access to a scale. The goal isn’t to get a perfectly good measurement of the weights of the 100 laptops in a pile in front of you, the goal is to get a pretty good estimate of the weight of the laptops in front of you. Finding the exact weight would be too time consuming, we might want multiple scales to make sure our scale is accurate, we might realize half way through that some of the laptops have the battery missing, so we need to go back and measure those again – these are details that we don’t need to worry about when trying to estimate. OK, metaphor over-used now
Since we can’t be perfectly accurate anyway, what we care about is relative weights. I think if we had a universal scale of story points, we would have some teams that are always working in the .5-1 story point range, and others that are always working in the 40-100 story point range. This doesn’t give the team a whole lot of insight into how big the various stories are in relation to each other, just that the stories they are working on are very small or very large in relation to the average.
Gabe,
I agree that story points are good for giving rough estimates to business leaders. However, I have to question what’s the threshold that business leaders have to keep in mind. If team A estimated a specific task 40 points. Then team A got busy doing something else — that the manager had to move this task to team B. How useful is the previous estimate from team A to team B or to the business leaders? In point #1 — I try to expose these questions.
Giving rough estimates with unknowns is acceptable. However, how many unknowns is acceptable to work with? For points #2 and #3, I wonder if there is a limit to the unknowns that we have to account for. Look at the extreme, what if everything in the task is unknown — such as research tasks. How do you estimate that?
Here is a philosophical question about Agile. It started to mitigate the shortcomings and limitations of the conventional software development methods such as water fall. I wonder if their goal was really to improve over time, or was it to find a solution and when they failed (if they did) they modified their goal to improve over time. :-p
Thanks for your comments Pickle and Gabe.
Khaled,
I think when it gets passed to Team B they need to reevaluate the story points. The whole situation would need to be reevaluated anyway, so asking the team to determine their story points wouldn’t really slow things down too much.
As far as how you estimate something that is unknown…you don’t. That’s where you use scrum’s “Time Box” concept (maybe its not just scrum, I don’t know). You say “we can’t estimate this, but I am going to spend 2 days researching this, and then see if we can make some better estimates on it”.
If truly everything about it unknown, either leadership didn’t provide a very clear story, or they need to understand that some research is needed to find out how much research is needed. Sucks, but its closest to the truth, I think.
I don’t know what to do about #3, as you know. Maybe we can get good at estimating the overhead for such non-functional requirements? Really though, if those non-functional requirements (including QA) are made part of the acceptance tests, then the team velocity should reflect that fact. If something is particularly complex, then maybe it deserves its own estimation, but its really up to the team to set those expectations for what they call “done”. I guess I’m just saying push the fact that those things need to be done on the team, the estimation part will come naturally.
Haha, your last comment is some agile zen