I was having a discussion in the team to create an Epic for all the technical-debts in the project. The problem is, as per definition Epic should not spawn more than a quarter, but, if we create an Epic for technical-debt it may run for the duration of the project. I surfed on Internet but could not find anything. Please help with right Agile guidelines.
-
Consultants sell Agile; there is the agile philosophy.– Alan LarimerCommented Apr 4, 2018 at 11:52
-
2What are you trying to do by rolling all your tech debt into an epic? Is this for time tracking, traceability, or...? From an agile perspective, this is likely an anti-pattern, but from a JIRA perspective there might be a business case.– Todd A. Jacobs ♦Commented Apr 4, 2018 at 12:58
Add a comment
|
4 Answers
An epic is a large story. One that needs to be broken down into stories that fit comfortably within sprints. It isn't really meant to be used as a way of grouping stories together in a category.
Having said that, do what is best for your team. If you find grouping technical debt tasks under an epic helps you to track them, then that is fine.
My preferred approach in JIRA is to use a "technical debt" label on stories/tasks that relate to technical debt work. That way you can filter in/out technical debt work items if you need to.
answered Apr 4, 2018 at 10:24
-
2I'm not sure why this answer attracted a downvote. I think the tracking use case is a reasonable one, and using labels rather than epics seems like a good JIRA-centric solution in many cases.– Todd A. Jacobs ♦Commented Apr 4, 2018 at 13:02
-
1+1 for lables. Also, it lets you run a quick query to see how many tech debts stories are appearing which gives you another data point into the team for supporting them. Are they being pressured? Is it drive-by coding? Are they rushing to close tickets? Is the codebase becoming unwieldy? etc etc Commented Apr 16, 2018 at 13:20
The right agile guideline is that you should do what works best for you and your team.
There is no right or wrong with using an Epic to label the technical debt in the project. But there is also no requirement to have all stories associated with an Epic.
answered Apr 4, 2018 at 7:36
-
1I didn't vote on this answer yet, but: 1) I think it's more of a comment than an answer; and 2) there are trade-offs and best practices, so hand-waving it doesn't answer the question either. Please consider improving your answer before I vote on it.– Todd A. Jacobs ♦Commented Apr 4, 2018 at 13:00
So, we need to discuss Technical Debt
You accumulate technical debt when you make a strategic compromise (to meet a date, or ship something), but this is a short term thing, you are supposed to fix it ASAP, possibly by adding a new story in the next sprint (likely as part of the original epic) to fix it.
If you have a large accumulation of compromised items which have not been worked on for some time, this isn't technical debt, it's poor design or bad development practices.
You need to create new stories to fix these and prioritise them. You likely need to prioritise some time/velocity per sprint to deal with them (instead of new work) .
Don't add them to an epic, they will end up being deprioritised and never done. You may also reward yourself with velocity for dealing with things that should have been right the first time.
You need to block time to show that compromising deliverables like this reduces velocity so should avoided.
answered Apr 15, 2018 at 22:51
-
Tech debt could also be an artifact of a design pivot or evolving best practices but otherwise +1, Tech Debt should be paid off in frequent small installments– LiathCommented Apr 16, 2018 at 12:21
-
According to the Tech debt quadrant, there are multiple reasons why Tech Debt might appear. For more nuanced then you are making out.. A view supported and endorsed by Martin Fowler. For instance...lack of developer knowledge is technical debt. martinfowler.com/bliki/TechnicalDebtQuadrant.html Commented Apr 16, 2018 at 13:23
As already said, this is not agile issue, but rather a question how to groups certain issues in JIRA. I've been using JIRA's sprints for that. There is no auto-grouping by label or by epic in the backlog, so it's hard to see all the 'technical debt' issues in one place, unless you sort them manually. So I add such issues to a 'Technical Debt' sprint, which is not a sprint per se, but a way to group them.
