how to estimate multiple stories with less complexity?

Question

We want to track user activity on this screen (attached image) i.e.

1. close button click (top-right)
2. User's tap on textbox (Type your city)
3. User's click on Detect my location

If we follow INVEST criteria, each of the above 3 is an independent story. As a rule, we give minimum 1 point to each story. Our team feels that these three are trivial tasks and it's not worth to give three points combined to these, it's just 1 point effort to execute all 3. We have following choices:

1. Create 3 separate stories and give 1 point to each: This would go with the INVEST criteria but the execution is not complex enough for 3 points. This might show increased velocity which is not actually the case here.
2. Create 1 story for above 3 things and give 1 point in total: We are combining multiple stories here but estimation is as per the complexity.

Note: This is a simple example and it's not just about 3 stories of 1 point, there might be 15 such stories.

Question is - how should we break the stories and estimate them in such cases?

Answer 1

I'm not sure in what way combining them would violate INVEST. The I (Independent) generally refers to if it is inextricably tied to another backlog item. For example, if I have a backlog item to make a database change and one to publish the change, they are inextricably tied to each other, so they are really the same backlog item. I would think doing all three together is fine. Now, there is an argument to be made that you may want to prioritize them separately (or some not at all) and then an argument could be made for keeping them separate, but if you definitely want to do all three, grouping them should be fine if your team wants to.

Answer 2

A 1 is the smallest possible change.

For us for example, that means

• clone the repository
• set an attribute from true to false
• start the app
• check that it worked
• commit the changes
• push the changes
• close the ticket.

I have a hard time believing, that entering a city and detecting location is that simple. You'd need a geo location service, you'd need a key for that, you need to test it for multiple values (what happens when you enter an ambiguous value? For example if I enter "Hanover" while being located in Hannover, Germany, I get Hannover, Germany, even though there exists a Hanover, PA that would surely be a better match for what I entered. What happens if I press it when I have not entered anything? Error message?)

So if that all is too easy for a 1, you need to check back with your developers if they are actually on the same page with you. If that story is a 1, the smallest possible amount of work, your scale is off, simple as that. Because there obviously is less work possible.

---

Assuming a different example: lets say it were that easy. Just build a story that says

"As a user I want to select my city to filter (whatever)".

Done. Then note the details (needs to be it's own dialog, needs close button, needs input, needs auto-detection) as additional information for the story.

Answer 3

'Independent' is not the same as 'small' (the 'S' in 'INVEST') of course. A product Backlog item (PBI) should be as small as possible but no smaller. It is possible to go too far and split into subatomic parts that would be more usefully kept together. Anyone remember last year's deconstructed avocado toast scandal?

I would urge you to consider whether these items are too small. Could they be grouped and still be indepedent from all other PBIs and "small enough"?

Note there may be dependecies between your PBIs. I view 'independent' as an ideal that is not always attainable/desireable.

To demonstrate, let's say there was just one PBI to track user activity on the whole screen and the estimate comes out at 20 Points - too big! Devs look at splitting it and come up with four items: one to implement user activity logging (5 Points) and three for each UI element (3 points each). That's no good because none of the there is a dependency in that the 'implement' item must be played first and in itself delivers no value. One approach is to combine the 'implement' item with one of the 'element' items to make one 8 Point item that delivers (limited) value. Now the remaining two 'element' items will still be dependent on the first but should retain a lower estimate (3 Points) because they can be written as, "Assuming user activity logging has been implemented..." then the cost at the margin (i.e. the cost to get your established factory to produce one more widget).

Answer 4

I agree with Daniel, it doesn't violate INVEST.

I want to add that although you can manage it as a single story, if it's relevant for your project, you should still record this effort in the bigger component that this tasks are linked to (they seem to belong to a different component?) so that they can be used in the future to fully understand how much effort has been invested in such.