Should only functional user stories estimated ? What about technical, QA user stories
Hi
I would like to hear more estimating different types of user stories. I came across one thesis in one forum that only functional user stories should be estimated. because those are adding direct value to business.
But apart from functional user stories, team is spending time on below types of tasks/stories.
- Technical users' stories ? e.g. Data clean up, indexing, configuration etc.
- Engineering initiatives ? e.g. PII encryption, Application Security etc ?
- QA Regression testing/Automation testing/Load and Performance testing etc
So weather we should give story points to above 3 types of user stories also. Or if not, then how team's velocity will be calculated at last ?
Or if any best approach, please suggest.
Thanks in advance !!!
Why is the team estimating?
In my experience, many teams estimate time or effort to support planning and forecasting work. If that is the purpose of estimating, then it doesn't make sense to estimate a fraction of the work that the team spends time or effort on.
Other teams may estimate in order to ensure that they agree on the defined scope of work. By having individuals estimate a unit of work and then comparing the estimates, the team can see if someone may have a different understanding and more time should be spent to define the work and the success criteria. In this case, it still doesn't make sense to estimate only some of the types of work, since the uncertainties and ambiguities that you want to detect exist in all types.
In a third case, the team may estimate to decide whether it's worth doing the work. If the team has an idea of what the value of the work will be if completed and can estimate the time or effort to complete the work, they can see if the value of the work is sufficient to justify the cost of doing the work. In this case, some types of work may be determined to be necessary regardless of the cost, and it wouldn't be necessary to estimate those types of work.
These aren't the only reasons to estimate. Until you can define why the team is spending time and effort estimating, you won't be able to figure out what you should be estimating. Depending on the rationale, you may also want to consider techniques other than estimation that could help the team accomplish the same goals with less effort.
how team's velocity will be calculated at last
The only purpose of estimation is so the Developers can get their arms around how much work they can take on in a Sprint. Everything else reduces to value delivery and empirical process control.
Velocity is the rate at which work is Done so empirical feedback can be obtained. We are not in the business of being story point accountants.