Now think about another web page also with 100 fields. Think back to the earlier example of developing a web page with 100 trivial text fields with no interactions between them. ComplexityĬomplexity should also be considered when providing a story point estimate.
Point measure code#
If implementing a feature involves changing a particular piece of old, brittle code that has no automated tests in place, that risk should be reflected in the estimate. If a team is asked to estimate a product backlog item and the stakeholder asking for it is unclear about what will be needed, that uncertainty should be reflected in the estimate. The amount of risk and uncertainty in a product backlog item should affect the story point estimate given to the item. There are, after all, economies of scale and maybe making the second page is only 2 or 3 or 10 times as much effort as the first page. It probably doesn’t get 100 times more points even though there are 100 times as many fields. The second page should be given more story points. The only difference between these two pages is that there is more to do on the second page. There’s no additional risk on the second page. There are no interactions among the fields and each is nothing more than a bit of text. The second page has 100 fields to also simply be filled with a bit of text. The first page has only one field and a label asking to enter a name. Consider the case of developing two web pages. The Amount of Work to DoĬertainly, if there is more to do of something, the estimate of effort should be larger. Let’s see how each impacts the effort estimate given by story points. When estimating with story points, be sure to consider each of these factors. Any risk or uncertainty in doing the work.Because story points represent the effort to develop a story, a team’s estimate must include everything that can affect the effort.
0 kommentar(er)
