Do we size bugs with story points?

I found a question posted in one of the social channels at work: How should one give out story points to bugs/defects that one does not yet know how to fix yet and requires investigation? The original question asks how but I think even before we go there it would be nice to know whether we need to in the first place. I plan to write about this in 2-parts: (1) how I might go about with it — no explanations, but based on past experiences as a member of Agile Scrum teams and what I’ve read on the topic, and (2) links and quotes galore.

How I might go about with it

  • If it’s a bug found during testing of a user story we’re working on in the sprint AND it’s small enough (implicitly sized) to be fixed within the same sprint: It goes into the sprint backlog. No need to size it. Just prioritize it accordingly.
  • If it’s a bug unrelated to user stories that we’re testing this sprint (say, from an older feature) OR it’s too big a bug or complex (again implicitly sized) to be fixed within the sprint: It goes to the product backlog. It’ll be groomed as you would with other user stories to give it enough details for the team to work with. And if it makes it way into the Sprint Planning, then size the bug.
  • Now what if the bug that goes into the product backlog requires more investigation than usual (all bugs require investigation, but in some cases I suppose devs already have an idea of how to fix it, in some, totally no idea hence more investigation is needed): Tag it as a spike (not a term in the Scrum Guide, FYI). If it goes into the Sprint Backlog, meaning the team agrees to invest time on investigating that bug within the Sprint, no need to size it.
    • For that spike in the Sprint, it’ll just mean there’ll be a time-box (1-3 days of effort) for investigating that bug. At the end of the time-box, whoever works on it reports their findings and the team can discuss the next steps.
    • Assuming the team agrees on a resolution, duplicate the bug with the spike tag. Close the original one. In the duplicate, remove the Spike label. If it’s to remain in the Sprint Backlog meaning the team will fix it within the Sprint, then size the bug. Otherwise, the new bug (the duplicate) goes to the Product Backlog and no need to size it yet.
    • But what if there’s still no resolution or identified workaround. The team can opt to extend the time-box. But at some point, you can’t just extend and extend it forever. Once a threshold is met (is 3 months too long/short?): Tag it with a label your team agrees to use on such items, and then archive it.
  • At the end of the Sprint, the Scrum Master will be able to gather the following data in case they want to use it for some forecasting:
    • User Stories – total story points, bugs per user story
    • Bugs – total story points, total number of bugs
    • Spikes – total number of Spikes worked on, total number of Spikes closed, total points from Spikes that were converted to new bugs

That turned out longer than I expected. The next part are for some links on the topic and could give you the opposing views to help you come up with your own answer.

Links and quotes galore

12 common mistakes made when using Story Points – This has a lot of other interesting points not just about on whether you size bugs or not.

  • “Story Points represent the effort required to put a PBI (Product Backlog Item) live.” So story points are not limited to user stories.
  • “Story Points are about effort. Complexity, uncertainty and risk factors that influence effort but each alone is not enough to determine effort.
  • [Common mistake #5: Never Story Pointing Bugs] “A bug which is unrelated to the current sprint should just be story pointed. The bug represents work the team needs to complete. This does not apply if the team reserves a fixed percentage of time for working on bugs during the sprint. A bug related to an issue in the sprint should not be story pointed as this is part of the original estimation.”

Should Story Points Be Assigned to a Bug Fixing Story?

  • [I think this is with respect to legacy bugs or when the team is dealing with a large database of agile defects] “My usual recommendation is to assign points to bug fixing the agile defects. This really achieves the best of both worlds. We are able to see how much work the team is really able to accomplish, but also able to look at the historical data and see how much went into the bug-fixing story each sprint.”

Should you ‘Story Point’ everything? – This is a thread in the Scrum.org forum.

  • (No points for bugs) ‘They are called story points for a reason. They are not call[ed] “Item Points”. Ideally you should only have stories in your backlog and the technical tasks should be inside…’
  • (Yes or no points for bugs) “It is critical as a Scrum Master to ensure that story points are being used properly within an organization. They serve two purposes only: to help the Development Team and Product Owner plan future sprints, and to be accumulated for done items at the end of a sprint for velocity calculation purposes. They are not a proxy for value delivery. … That said, it seems there are a number of different items (bugs, technical tasks, spikes) that have a capacity impact on the Development Team each sprint. For planning purposes, if the team prefers to not point these items, a mechanism to determine the capacity impact is still desired….”
  • (No points altogether) ‘I have found, and this may depend on your team, that removing story points entirely helps the team and stakeholders focus on the sprint goal instead of “How many points”….’

What’s a spike, who should enter it, and how to word it? Since I mentioned “spikes”, I’ve put in this other link about it.

  • “A spike is an investment to make the story estimable or schedule-able.”
  • “Teams should agree that every spike is, say, never more than 1 day of research. (For some teams this might be, say, 3 days, if that’s the common situation.) At the end of the time-box, you have to report out your findings. That might result in another spike, but time-box the experiments. If you weren’t able to answer the question before time runs out, you must still report the results to the team and decide what to do next. What to do next might be to define another spike.”
  • “It’s also best if a spike has one very clear question to answer. Not a bunch of questions or an ambiguous statement of stuff you need to look into. Therefore, split your spikes just as you would large user stories.”

Let me know if you find anything more conclusive or helpful.

Reads from this morning

Trigon, this app I occasionally play, can be such a time sink. I’d say “just one more game,” then after a while, I’d realize that an hour had just gone buy and I spent it just arranging shapes to align and disappear (pretty much like my time). So I caught myself this morning just about to tell myself “just one more game,” and decided to get back into my reading in Medium. Ended up bookmarking several stuff and reacting to a few.

“Active reading — taking notes, sketching, and talking with a friend about the text — can also help forge mental connections between the information you’re taking in and what you already know, increasing your retention. This doesn’t mean passively highlighting, re-reading, or retyping what you’re reading but effortfully engaging with the text: jotting down your own thoughts, questions, and connections that occur to you, whether you do it in the margins or take notes elsewhere.”
How to Remember More of What You Read

Sometimes I have instances of “I’ve read somewhere that so and so…” and vaguely recall an idea from a book or text I’ve read. Or I’m able to connect something I’ve read about to something at work. To have been able to pull something out of the well of insights I gained from reading tells me that I do remember enough to make some use of it. With the little I remember (I admit to not having the best memory which is why I like that quote saying the mind is not a vessel to be filled but a fire to be kindled), the information and even knowledge I’m able to connect to real life has been helpful. I can only imagine how much more so if I can remember more. I’ve started doing that to some of the books I’ve been reading since September i.e., more actively highlighting, taking down notes, and occasionally putting in some lols and side comments. Whether my memory improves, I’ve yet to find out, but at least I know where to find my notes if I need them.

“A great culture can ensure you are able to do something repetitively if you have done it before. It brings sustainability. It brings certainty in outcomes.”
Well, culture DOESN’T eat strategy for breakfast!

I’m not exactly in charge of culture building at work (but I do know my behaviors, my mindset, how well I execute has the potential to contribute to the culture). Nevertheless, I found this post and the book it shared (“What You Do Is Who You Are” by Ben Horowitz) interesting — especially the little anecdotes. No PowerPoint presentations in meetings. Just kill the snake, don’t play with dead snakes, opportunities start out looking like snakes. Shocking rules. Don’t !@#% the customer as a value. Interesting.

“In late 2019, the US Court of Appeals denied LinkedIn’s request to prevent HiQ, an analytics company, from scraping its data. The decision was a historic moment in the data privacy and data regulation era. It showed that any data that is publicly available and not copyrighted is fair game for web crawlers.”
Web scraping is now legal

This just throws me back to when our team was looking into LinkedIn integration to strengthen the expert profiles in the in-house app we built. Crawling was an idea we were cautious about since we feared the legal implications (so we obviously did not go there).

Other reads from this morning before my Trigon time was up 🙂

One link leads to another

Sometimes I come across posts or material in the internet on topics that piques my interest. It could be something I want to know more or understand more about. Or it could be related to a conversation or two I’ve had within the day that makes me question certain things. So sometimes I google, and sometimes I just stumble upon them through various feeds — could be Twitter, email, Medium, IG, and Facebook even. And then one link leads to another and before I know it, it’s 2AM and I should be getting some sleep. So anyways, here’s a dump of some recent links, in no particular order. I hope someone finds them helpful or interesting as I have.

Agile Product Ownership in a Nutshell (15 minute video) – I like how the content was easy to follow. There were a lot of points worth highlighting, but I guess what hits home the most is the mention of three things that need to be balanced:

  • Build the right thing (PO tends to focus here)
  • Build the thing right (dev team)
  • Build it fast (SM or Agile coach)

So you want to be a Scrum Master (book) – This is a Leanpub book which you can get for free, or not if you can afford to make a payment / contribution. It’s written by an Agile community of interest with the intent of sharing what they’ve learned and what they’ve seen to have worked.

The 3 most effective ways to build trust as a leader (post/article) – Got this from Rob Lambert but I can’t remember where exactly — “Three typical management activities that get poor results and three that get good results”. I’m not really a leader by title but the three ways of building trust that the post enumerates are still relevant to me and they emphasize points that I value: Empathy, clarity of intent, and follow through.

DISC Profile Types (personality test) – This is something I picked up from Rob Lambert’s webinar. For each profile type, there are recommended ways on how to better communicate with them, and inversely there are recommended ways on how to encourage others to better communicate with you. Took the test myself and got 48% Compliance, then Dominance, Steadiness, and lastly Influence.

12 common mistakes made when using Story Points (post/article) – This reminded me of something a colleague had shared wherein their Scrum Master wants them to estimate in hours rather than in story points, and also her thinking that story points can be easily translated to hours.

Agile Makes No Sense (post/article) – Let me just quote some lines (actually last 2 paragraphs) that I liked…

What is the smallest thing that could add value (and make sense)? A better standup? A better retrospective? Inviting a customer to a demo? Pairing for a day? Agreeing to get something into product in a couple days? Try that. Make one thing make sense as in “wow, I can see how that created value”.

When you take this humble approach — instead of “installing” a bunch of artifacts, tools, roles, and rituals AKA doing Agile — I think you’re embracing the true spirit of Agile.