0

To give a background, We are web automobile company having a new and used cars portal, something like autotrader usa

We have lots of technical debt pending i.e. moving our pages to new backend technology, updating the versions of various open source modules we have integrated, modularizing the javascript etc.

The problem is, should we give points to these or not?

Why team wants point for chores:

  1. There is a lot of legacy code that team says should now be considered as a feature since the majority of the team members never worked at the time when this legacy code was put to production.
  2. They say velocity measures "how fast team delivers", why shouldn't we count things like exploring new technology like a unit testing framework or new UI framework like React, upgrading existing software to higher versions, moving to better technology in the team's velocity, isn't these things worthy enough in fast moving technical world?
  3. Many times PO suggest to take short cut approach rather than ideal technical approach either due to business pressure or to quickly see the results. If the experiment succeeds,the same thing needs to be done in a proper manner. This is technical debt, why shouldn't we count this in velocity?
  4. Automating release process- this does not impact customers life, so it should be chore ideally. But it saves team's time and headache. Why we shouldn't give points to it?

Why it shouldn't be given points:

  1. I believe if the team is smart enough to pick right chore activities time to time, this would automatically start showing up in velocity in future sprints. For example, if they start using a unit testing framework (done as a chore with no points), in future, there would be fewer bugs and team would be able to deliver more.
  2. If a team has to deliver 300 points in next 3 months, and they ask PO for clearing technical debt in the first month, so the team would be delivering 0 points in the first month. But the team should pick stories that would clear all technical hurdles so that team now can deliver 300 points in next 2 months. This would motivate the team to pick the business aligned technical debts and not random stuff to decorate their resume.
Improve this question
2

2 Answers 2

Reset to default
1

The simple answer would be if the team is working on an item then it should be estimated. As an example if the PO decided to run a technical debt sprint, addressing no new features, at the end of the sprint, if there was released software, why wouldn't there be a velocity for this sprint?

Work is work after all.

The only issue arises when a technical team wants to upgrade to new technology ... but the PO doesn't see the value in it. Its OK at times to run old code as long as the underlying business processes are running and generating business value. (And the maintenance of it isn't excessive)

So I'd size chores, it gives a better reflection of what the team is actually doing during a sprint.

Improve this answer
1

There's a school of thought that says:

Don't estimate bug fixes, chores and spikes.

This is because points should only be awarded to work that adds value to the business.

Developers should be given an incentive to complete the most valuable work. They get kudos for burning down story points because those stories represent direct business value.

By contrast, they are encouraged to complete bug fixes, chores and spikes as quickly as possible, because those activities don't directly add value, and they don't get as much credit for completing that sort of work.

There is supposed to be a healthy tension between the business and the developers, and this system formalises it.

Sources:

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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