0

Recently our team has decided to give points to the chores. They had an argument that:

  1. Velocity defines team's capacity to deliver the work and if chores are not counted in velocity it won't reflect the true capacity of the team. As teams pick chores as per the business priorities/urgency i.e. in some sprint 1 or 2, in other up to 5 chores so, they feel the more chores they have the lesser would be velocity/capacity of the team in that sprint which might not be true.
  2. They feel chores also add value to the product i.e. if we have some duplicate logic and we plan to remove it as a chore. In long run, it would help us deliver and test things faster and hence, it delivers value indirectly to the user.

What could be downside of this approach?

Improve this question
2

3 Answers 3

Reset to default
2

I'll share some potential downsides, but I'd be hard-pressed to say this approach is wrong if it's working for you. There are some reasons that I wouldn't do it, but that's different than wrong. So here are a few potential downsides:

  1. It sounds an awful lot like "getting credit". Only you and your team know if you're in that mindset, but I see a lot of teams that give points to work that is tech debt, refactoring, or otherwise not building out the product because they want that work to count on a report to a superior and that runs counter to the values of Agile and Scrum.

  2. It's better to tie technical debt and refactoring to the value it produces. If I had to refactor a database and data access layer to support the inclusion of new customer data, I'd rather wrap that work into the user story for that customer data so that the true cost of the delivering that value is clear rather than hiding part of that cost deferred or hidden. There are two edge cases with this to consider:

    • There will be a period of time where you have refactoring and technical debt whose value is long-since delivered and you can't reconnect it. That's normal. If you connect new technical debt and refactoring, this will become less and less common.

    • There will be times you miss it. Even the best teams do. It's a great topic for a retro, but nothing for the team to beat themselves up about.

  3. It can hide the impact of overhead. If I get 25 points completed on average because I've got a bunch of overhead to deal with, but then I give that overhead points and now I get 33 done on average, now it looks like I'm getting more value produced, but I'm not. Personally, I feel like this takes the focus off of value and just accepts certain inefficiencies in how we're writing software.

  4. It can make forecasting difficult. A lot of stakeholders and product owners use average velocity and burnup charts to forecast progress on a release. If some of the velocity moves the product forward and some of the velocity is just overhead, it can become almost impossible to make that forecast.

Improve this answer
3
  • I understand your point, but story points measure effort, not value. If the team has a velocity of 25, but can only plan for 17 story points from the Product Backlog per iteration because they routinely have 8 points of recurring interest on their tech debt, then the source of the drag should be clear whether points are assigned to the tech debt or not. Either way, inflation happens when velocity tracks implicit or explicit work not visible on the Product Backlog,
    – Todd A. Jacobs ♦
    Dec 28, 2017 at 23:40
  • You could argue that in your example your team actually has a velocity of 17. The way I look at it: the velocity is the rate at which a team delivers business value. From a PO perspective it doesn't really help that the team 'did a lot of work' but there is not much to show for. So I concur with the 'getting credit' point.
    – Ray Oei
    Dec 29, 2017 at 11:48
  • @Todd - Thanks! There is a 4th point I missed about forecasting that speaks a bit to why I'd treat effort for product different from effort for overhead. As I said though, these are all potential downsides and reasons I prefer not to use points for those items. If it's working well for someone else and they've worked around these risks, I'd be hard-pressed to say they're wrong.
    – Daniel
    Dec 29, 2017 at 17:49
0

I do not see an issue accounting for all tasks/user stories, bugs, technical spikes, refactors, etc., as over time it allows the team to better understand capacity, and you can do a bit more analysis into where points are being spent to further optimize the teams workload and focus. If you do not have a tracking mechanism for these kinds of things then it's nothing you can ever have an honest conversation about, e.g., lack of focus on reducing technical debt each iteration, growth / increase in time spent on defects/defect density. It also helps teams build a case for refactoring if you have data to back up capacity allotment, increase in time spent on defects, etc.

Improve this answer
0

Small refactorings are encouraged (and not tracked) during development. If you have to add a feature in a class, try to leave it cleaner than when you entered into it.

Big refactorings must be estimated, valued and tracked, since it's a big effort. Obviously, you don't want to get there ever. That's why we try to make small refactorings everytime we can.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.