How to handle similar/re-usable work when estimating story points?

Question

In our Jira board we might have 5 tickets for different API endpoints - for example:

• ListArticle
• GetArticle
• CreateArticle
• DeleteArticle

When we create these new endpoints, there is some initial work that needs to take place to get our infrastructure ready for the endpoints. This only needs to be done once across all these endpoints (it's a requirement for all of them, but only needs to done once to satisfy the requirement across all endpoints).

How do we take into account this work when estimating story points for these tickets?

What we've been doing currently is to incorporate that pre-requisite work into just one of the tickets, and then estimate the other tickets as though the pre-requisite work has been completed. Is this a good way of doing it? Or would we be better off extracting that pre-requisite work into its own ticket?

Answer 1

There are a couple of options that I've seen work.

One option would be to put the initial work into its own ticket and identify the dependency between the initial work and the work for each specific endpoint. You would estimate each one independently, knowing that the initial work would have to be done before or with the first endpoint. Although it does add a dependency that needs to be tracked, it gives the team flexibility in when the work happens. The initial work could happen before any of the endpoints are implemented and then the endpoints could be implemented in any order going forward.

A second option would be to estimate the initial work as part of each of the endpoints. Although this inflates 3 of the 4 estimates (unless you go back and reestimate), it has the advantage of not needing to track a dependency. You still have the flexibility to choose the order of implementing the endpoints.

I would tend to avoid the approach you are taking now. Work should be as independent as possible. Right now, your estimate is built into one ticket. If the desired order changes and the team forgets this, they could end up overcommitting themselves and stretching too thin for a bit or rushing to get things done, both of which would have a negative impact on overall quality.

Ultimately, though, the team should decide. Perhaps the way you are doing it now is working well for the team. In that case, maybe you shouldn't change, but do be aware of the potential problems during planning sessions.