Tracking Unexpected Work and Bugs

At the end of each sprint we will add these hours up and convert to story points

If you are able to map hours into story points (and the other way around), what is the point of using it in the first place? 

Outside requests that come in during the sprint should be put in the backlog to be estimated and prioritized. If essential, that work will need to be brought into the sprint which will change the scope. This is obviously something that we want to avoid

How this support i.e.: this Agile Manifesto value and principles?

• Responding to change over following a plan.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Business people and developers must work together daily throughout the project.

Or how this support such things like inspection and adaptation? What is the purpose of Daily Scrum in that context?

Do we truly want to avoid scope changes? Is re-negotiation of scope "allowed" or not during the Sprint?

What is the purpose of tracking all of these points and doing this kind of maths that you described above?

What kind of problem are you trying to resolve by this?



Are you (as a team) exist to deliver story points, or there is other purpose than that? If it is the latter, then maybe you are focusing on the wrong thing now?

Daniel Barber, your idea of considering a bug (found by the team) as part of the original PBI is correct. But that's all you have to do. The story point is a RELATIVE estimate. The same team working on same product backlog will have rather consistent story points assigned to similar PBIs. Over time the estimates may get better. But all you have to do it the average velocity of previous sprints to forecast the amount of work the team can take in the next sprint. 

Remember that the velocity is to help the team plan its work for the next sprint and not for any other external reporting. It helps the Product owner to forecast how much functionality can be done in the future releases. 

When the same team works on the same product backlog, the kind of bugs and the improvements they do to their definition of done and coding practices that they adopt to improve the quality will automatically adjust the velocity with each sprint and the forecast is only an anticipation based on what we know from the recent sprints. A similar PBI from next sprint will have similar work and similar bugs, so no need to do any adjustments and calculations to find the value of a story point in terms of absolute units of time. 

Story points have no intrinsic value and they are RELTIVE in nature.

Without knowing what tools and configuration, I can share a few thoughts about your idea.

The teams that I've worked with used to use sub-tasks for bugs when working on a particular story or task. However, there was some overhead with creating those sub-tasks. We found that this was really not necessary. If the bug was found in the initial development, it would just be fixed. If it was found during a later test, such as a QA or Product review of the work, the work would just move backward in the workflow with a comment explaining why. However, some teams really didn't have a problem with the sub-tasking. One issue that did come up is if the Product Owner was reviewing the increment and found something of note, it was often difficult to pin the bug to a particular story or task and move that back.

The whole idea of converting between Story Points and hours is greatly troubling. I don't think that this is wise - there should be no relationship between relative effort or complexity of a unit of work and hours. Sometimes, a very complex piece of work ends up moving very quickly because things just went very well. Other times, a very straightforward piece of work takes a long time because of other factors unrelated to the work. Treat points and hours what they are and don't mix them.

I do think that it's important to visualize all of the work that you are doing, whether it's planned or unplanned. Making sure that the team and other stakeholders can see the impact. This is especially useful if you don't achieve your Sprint Goals. If you received a large amount of unexpected work, you can reflect on that during the Sprint Retrospective. Rather than trying to estimate and account for unplanned work, I'd want to find ways to eliminate the unplanned work.

The team is relatively new at Scrum so we are trying to make sure we get an accurate bead on our velocity. To speak to your second point, the team often gets pulled in several different directions. We certainly are not opposed to scope changes and adapt to them as they come up but we do want to monitor them and it would be nice to know how much of an impact that is having on our sprint. As for the bugs, we have a tendency to max out our developers time with new feature development so it would be nice to be able to set some time aside for them to work on bugs, this is designed to track an average of how much time each sprint we would need. Theoretically, you would only need about 3-4 sprints worth of data to start accurately predicting this time.



If you have a recommendation for another way I am certainly open to hearing it. 

There seems to be a little bit of a delay from posting a reply to seeing it show up and now I see that a couple more comments.



So it seems that the general consensus is that the DevOps idea is unnecessary and potentially inaccurate when converting hours worked into story points. So bugs that are in the backlog for released features should be estimated and pulled into the sprint as individual items while bugs for features in progress should be sub-tasks of those features, using the previous relative estimate for that feature.

I am still a little foggy on what to do with the Unplanned Work story. I want to track this for reporting purposes as Thomas mentioned but I do not feel comfortable with the arbitrary 13 story points that we currently assign to that task. We strive to adapt to changing priorities and I think the team does a great job on that but I want to be able to record it accurately. For work that is in progress, I think it should fall under the original estimated ticket, I dont think theres any disagreement there.

My goal with this was simply to get an understanding of roughly how much time we spend on planned work vs unplanned work/outside requests vs bugs so that we could plan for that in our sprints. 

Personally I am not a big fan of practices like blocking ghost PBI dedicated for bugs estimated for X points or whatever, or vaguely setting rules like "reserve 20% of your time / capacity for such things". Maybe for some teams it works, but personally I never seen this working 'as designed'.



I'd rather prefer focusing on creating good habits and environment that reinforces them. Why? Because I believe that word team means something more, than a group of people only working together. So, long story short, I am a big fan of creating time-boxed activities that live within the sprint, just like we do it in our private life. For example, when you plan to go to the gym, you do it by saying: "I will spent 10% of my capacity in the gym" or rather you are saying: "I will go to the gym twice a week for max 1h each time"?



So, going back to bugs, what you know is: bugs will always hunt you, that is the nature of software development. What you don't know is: how many they will be this time? So as it is infinite game, maybe consider creating a habit? (it is oversimplified) like i.e.: We will spent 2h each Friday on doing known bugs, refining / refactoring used tools, processes, developing yourself, sharing knowledge etc.



Above things are rarely considered by POs out there, as they at first glance bring little to no value, exactly as going one time for 4h to the gym - it won't bring much value for you either. But, what will happen if you will be consistent and go regularly to that gym for 20min? I bet that it will get you into shape. It is a compound effect that only brings value over long period of time.



So ask yourself some questions (as a team):

• Do we have a habit to think about Goals, not about tasks in the first place? 
• Do we have a habit to seek opportunities to fix things (like bugs) by our initiative when unexpected "free time" emerges?
• Do we have a habit to regularly spent time for improvements (even small ones) and self-development?
• Do we have a habit to never decreasing our agreed level of quality?
• etc.

I recently started at a new company and my team has been experimenting with how to track unexpected work and bugs in their sprints.

See the Bradley Bug Chart: https://scrumcrazy.wordpress.com/2018/09/22/one-way-to-handle-production-support-and-bugs-in-scrum-bradley-bug-chart/

A defect discovered in-Sprint implies that more work is needed for the increment to be Done. This should be handled accordingly, such as by replanning tasks. A defect found after the Sprint has finished implies that technical debt has been incurred. This should be accounted for on the Product Backlog and the Definition of Done improved.

My goal with this was simply to get an understanding of roughly how much time we spend on planned work vs unplanned work/outside requests vs bugs so that we could plan for that in our sprints. 

How about focusing on how much time you spend delivering value to the stakeholder?  That is all that really matters.  And I can already tell you that the answer should be 100%.  Don't focus on the time you work or the number of items you complete in a Sprint.  Those are just data points that can be interpreted in many ways.  Focus entirely on the ability to be delivering potentially releaseable increments of value at the end of each Sprint.  If you are not doing that, then the team should investigate, arrive at experiments that could improve the ability, and then investiage and experment again until they come up with something that works knowing that what works now could become a hindrance later. 

Plan your Sprints by selecting a set of items from the Product Backlog that will deliver a potentially releasable increment of value that your Development Team feels they can complete. That increment becomes your Sprint Goal.  One Sprint that could be 4 items while another Sprint might need 9.  If you find that the goal is endangered in any way, adapt.  Whenever something comes up that needs to be addressed, inspect that based on the ability to achieve the Sprint Goal. Even defects found while modifying code.  Is it necessary to fix that bug now in order to build the increment? If so, fix it. If not, then decide if there is time to fix it or can it become an item in the Product Backlog for a future Sprint. 

I also encourage seeing everything as equal. A Product Backlog item describes work that needs to be done to a product in order to deliver value.  That could be a new feature or a bug fix.  Both of those have 2 values.  A feature has negative value until it is delivered and then the value turns positive.  A bug has negative value as long as it exists and positive value when fixed.  But both could also become unnecessary in the value proposition to the stakeholder.  Evaluate everything equally in relation to the value to the stakeholder.  I even go as far as to say create only 1 type of item in the backlog.  Don't enter user stories, bugs and tasks.  Create everything as the same type (usually coach everything is a user story).  Pyschologically it helps to treat everything equally. Having different types usually leads to your situation of trying to determine how many of each thing can be accomodated.  Just accomodate value delivery.