How to estimating stories that are "less complex" but "effor is more" [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 4 years ago.

Improve this question

In Agile process story points are a measure of complexity and not of time. How does this holds good for a story which is less complex but more time tacking to complete.

Let me take an example,

Story 1: Save the user details.

Story points = 2. Typically Takes about 1 day to complete.

Story 2: The Company name has been changes from X to Y, and this needs to be updated in application. There are about 40 screen, 10 reports, Legal Notice all these should change.

This is typical example of a simple tasks but it will take a lot of time to implement (considering a localized application, even after following the proper standards of development) and test.

If I go by the traditional definition, I will give Story point 1, but then I am looking at a wrong velocity, the velocity will be down even after good work. I have seen this article which speak about the problem.

My question is how this task can be compared to the first story and should the effort be included in story point estimation?

I am almost convinced with this idea but would like to know the best practices used in such cases or if there is any good article I can read about it?

Answer 1

“The number of story points associated with a story represents the overall size of the story. There is no set formula for defining the size of a story. Rather a story point estimate is an amalgamation of the amount of effort involved in developing a feature, the complexity of developing it, the risk inherent in it, and so on." - from Agile Estimating and Planning by Mike Cohn.

In my development team we estimate stories in terms of size and complexity. The way I describe it to new team members is to consider size and complexity as two orthogonal axis on a graph. This allows stories that differ in complexity, but equally differ in size (effort) in the opposite direction to be considered relatively the same.

From personal experience, we found that if only complexity is considered then your team may unintentionally underestimate stories that require large amounts of effort to deliver. This will eschew your backlog estimates and makes it more difficult to use techniques like triangulation to keep estimates relative.

Answer 2

I do not know a bout a good article, but here is how we estimate activities using story points: first, we assemble as many people from the dev team as possible, with the product owner (PO, the decision maker from the client), the we make the PO explain a task/story/feature and then we use planning poker (with the PO as participant) to evaluate the complexity of the task, so the number of story points to allocate.

The important part here is that the complexity is different when viewed from the PO point of view or from any developer point of view. The example you give "changing the company name" might be very easy when viewed from the PO, but very complex because spread through the entire application from when viewed from the point of view of the developers.

Planning poker help us with a framework that lets everybody express his view on complexity. For us, it gives excellent estimates.

Also, remember that your story points do not represent the complexity of the story, but the complexity of the realization of the story.