If you're using Scrum, there's a minimum state that is necessary for a Product Backlog Item to be selected for a Sprint - the team believes that they can complete the work described within a single Sprint. However, if there are too many open questions or too many unmitigated risks, the item should go back in the Product Backlog and not be considered ready for selection in a Sprint. The amount to increase depends on how many questions, how much work it will take to answer those questions, and how many unmitigated risks there are. It will take work (effort) to work through questions to get answers or to mitigate risks, so this conceptually makes sense. If there are known risks that haven't been mitigated, it could go up to a 13 or 20. If I look at the description and I think it's about a 5 to account for effort, but there are still a few open questions that may impact the work, then it goes to an 8. I believe that underestimating work is far worse than overestimating, so an increase in any of the three factors results in an increase in story points. I also suspect that there's often (but not necessarily) a relationship between effort and complexity since complex work takes more effort to make sure that everything is right. At worst, you'd look at three factors - effort, risk, and complexity. Uncertainty is one form of risk, so you don't need to identify both. One way to think about it is to reduce the factors. I also don't think that approach makes sense. I don't think there's a mathematical function to take in effort, risk, complexity, and uncertainty in order to return a single value in story points. Teams tend to arrive at a common understanding of what point sizes mean.Įstimates really only have to be accurate enough for you to decide whether a story will fit into a sprint or whether it needs splitting. The team's estimates act as a sense check for each other. For smaller stories a point or two either way hardly matters.Įstimate as a team (wideband delphi / planning poker) and aim for a consensus. For the bigger stories you don't need to be so precise because the intervals between the numbers are large. Use Fibonacci or a modified Fibonacci series for estimates. Having a few familiar "baseline" stories in mind for comparison makes the estimation much easier. I certainly do take account of all the factors you mentioned but I tend to do it by relative comparison to previously completed stories ("this one is about as big/difficult/uncertain as this one"). I wonder if you are making too much of the details. Points are just an approximation however, and they make most sense when looked at in aggregate and over a period of time. Relative estimates (points) are useful because they tend to give a better approximation than absolute estimates and tend to be easier to work with. in your practice, do you use the aforementioned disaggregation? Why or why not?.if you describe a task's effort with these four metrics, how do you then combine them into story points?.is there a "theoretical" approach to aggregating these four metrics into story points? If yes, what is it?.simple), so I came up with a bunch of questions: Unfortunately, I don't have a clear-cut way of doing this (simple average seems too. as mentioned here) and then to combine these four into a "story point" estimate. Instead, I prefer first to disaggregate the story points into volume-of-work, risk, complexity and uncertainty (e.g. However, I noticed that I don't feel entirely comfortable giving a "story point" estimate, because it seems too speculative. Please correct me if needed.Īgile teams often use the "story points" metric for estimating a task's effort. Disclaimer: I'm a developer, so I don't claim to be thoroughly knowledgeable of agile practices, thus I may not always use the correct words and terms.
0 Comments
Leave a Reply. |