Paying down the tech debt

OpenLMIS Tech, lets take a moment to discuss our favorite topic: Tech Debt and how we address it.

To recap a few approaches we’ve tried:

  • We have a Technical Debt wiki page (which we don’t groom often enough - mea culpa)
  • We’ve turned them into Bugs (getting lost in the actual list of bugs)
  • We have/had a Component named Platform (which has everything from Tech Debt to future looking architecture)
  • We have/had a couple labels: TechDebt and TechBacklog (which I’ve transitioned so that we only now have TechDebt)

I think it’s fair to say that tech debt doesn’t always get prioritized, or the prioritization occurs too far removed from the developers whom have to live with the debt. To fix this I’d propose that we, the technical committee, start creating a cohesive tech debt backlog which we will groom for each sprint iteration knowing that we’ll always have a bucket of time set-aside to fix the technical issues that most need addressing.

To achieve this I propose we start with the following:

  1. Enter new TechDebt in Jira as a Task with the label TechDebt (it already exists and there’s a quick filter).
  • No Stories or improvements. Epics are okay.
  1. Transition the Task from Roadmap status straight to To Do.
  • We’re going to experiment with skipping Roadmap just for TechDebt.
  • This is not what we have in our Ticket Workflow , but we need to do this to use Jira grooming later.
  1. Once a sprint we, the developers and tech leads, will groom the TechDebt backlog by first prioritizing in the issue list, and then by ranking them on the board.
  • I’ll send out a meeting invite for sprint 51 to kick it off. Then perhaps we can move it to a slack channel.
  • Grooming the backlog is our responsibility and it won’t occur in the regular grooming sessions (which I think we should refer to as feature and bug grooming).
  1. As we start a new sprint, we’ll estimate w/ story points the top of our TechDebt backlog and place those into a dummy sprint we create named TechDebt Next.
  • I started this for Sprint 51, here’s a picture.
  • We’ll never start the Tech Debt Next dummy sprint, it’s just for organizing and grooming.
  1. We know we’ve estimated enough when the TechDebt Next sprint is roughly 20% of ourtotal estimated velocity.
  2. When our team’s next sprint is starting, we’ll pull items from the TechDebt Next sprint into our regular **Team’s Sprint. **
  • We can at this point delete the dummy sprint Tech Debt Next.
  1. During the sprint we can see which Jira issues are TechDebt with the Quick Filter Tech Debt.

Why a label?

We’re going to use a label as TechDebt can take a number of different forms, and we want a consistent way to find it.

How about Bugs?

Tech Debt could be a Bug, however I think more often than not a Bug should be kept as something that prevents an end-user from accomplishing a stated functionality of OpenLMIS. More importantly Bugs will be groomed and prioritized separately as they always have been. To control when we address some tech debt, keep it as a Task and label it TechDebt. If it’s a bug and it doesn’t have immediate value to the end user, it likely will be awhile until Bug Grooming prioritizes it.

The tech debt wiki page?

Lets start transitioning the items into Tasks in Jira with the label TechDebt. Once an item in that page is in Jira, lets remove it from that page and if we like this process we’ll remove the page once it’s empty.

Uhm, what is this Platform component?

This component tends to become a dumping ground of everything that doesn’t fit somewhere else. Lets not add tech debt to it. In fact I’ve re-named this component to Architecture to better distinguish where we find our Architectural backlog. My goal is to add issues to, clean-up and prioritize it to fit its name so that there’s an up-to-date issue list to see our Architecture priorities and wishes. I’ll continue to flesh items out in this component and get them groomed through the feature grooming process.

Skip Roadmap!? What about acceptance criteria?

Yes we’re skipping the Roadmap status and going straight to ToDo. If we didn’t then we couldn’t use the same agile jira board to groom the tech debt backlog as the one that holds our sprint - adding overhead. I also think that generally we the developers know what the rough acceptance criteria for tech debt should be, enough so that we don’t need a fully formed ticket and a separate status to move through to ensure everyone’s on the same page - for prioritization at least. We will need that well formed Acceptance Criteria to estimate however, so don’t use it as an excuse to leave the juicy details out.

Is this the way of things now?

Yes. For Tech Debt. Lets take control of what is slowing development down the most and start fixing. I’ll be looking to step out of the way quickly once we get a good rhythm going.

Thoughts? Questions?

Best,

Josh

Josh Zamor

OpenLMIS Architect

josh.zamor@openlmis.org

SKYPE: josh.zamor.vr

OpenLMIS.org OpenLMIS Wiki

Hi Josh,

I have two questions:

  1. How many Story Points every Sprint would be spent on fixing the tech debt? Would that be 20% of the Sprint capacity?
  2. Would the TechDebt backlog also include UI Tech Debts?
    Anyway, I really like the idea!

Best regards,
Nikodem


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Thu, Apr 5, 2018 at 6:06 AM, Josh Zamor josh.zamor@villagereach.org wrote:

OpenLMIS Tech, lets take a moment to discuss our favorite topic: Tech Debt and how we address it.

To recap a few approaches we’ve tried:

  • We have a Technical Debt wiki page (which we don’t groom often enough - mea culpa)
  • We’ve turned them into Bugs (getting lost in the actual list of bugs)
  • We have/had a Component named Platform (which has everything from Tech Debt to future looking architecture)
  • We have/had a couple labels: TechDebt and TechBacklog (which I’ve transitioned so that we only now have TechDebt)

I think it’s fair to say that tech debt doesn’t always get prioritized, or the prioritization occurs too far removed from the developers whom have to live with the debt. To fix this I’d propose that we, the technical committee, start creating a cohesive tech debt backlog which we will groom for each sprint iteration knowing that we’ll always have a bucket of time set-aside to fix the technical issues that most need addressing.

To achieve this I propose we start with the following:

  1. Enter new TechDebt in Jira as a Task with the label TechDebt (it already exists and there’s a quick filter).
  • No Stories or improvements. Epics are okay.
  1. Transition the Task from Roadmap status straight to To Do.
  • We’re going to experiment with skipping Roadmap just for TechDebt.
  • This is not what we have in our Ticket Workflow , but we need to do this to use Jira grooming later.
  1. Once a sprint we, the developers and tech leads, will groom the TechDebt backlog by first prioritizing in the issue list, and then by ranking them on the board.
  • I’ll send out a meeting invite for sprint 51 to kick it off. Then perhaps we can move it to a slack channel.
  • Grooming the backlog is our responsibility and it won’t occur in the regular grooming sessions (which I think we should refer to as feature and bug grooming).
  1. As we start a new sprint, we’ll estimate w/ story points the top of our TechDebt backlog and place those into a dummy sprint we create named TechDebt Next.
  • I started this for Sprint 51, here’s a picture.
  • We’ll never start the Tech Debt Next dummy sprint, it’s just for organizing and grooming.
  1. We know we’ve estimated enough when the TechDebt Next sprint is roughly 20% of ourtotal estimated velocity.
  2. When our team’s next sprint is starting, we’ll pull items from the TechDebt Next sprint into our regular **Team’s Sprint. **
  • We can at this point delete the dummy sprint Tech Debt Next.
  1. During the sprint we can see which Jira issues are TechDebt with the Quick Filter Tech Debt.

Why a label?

We’re going to use a label as TechDebt can take a number of different forms, and we want a consistent way to find it.

How about Bugs?

Tech Debt could be a Bug, however I think more often than not a Bug should be kept as something that prevents an end-user from accomplishing a stated functionality of OpenLMIS. More importantly Bugs will be groomed and prioritized separately as they always have been. To control when we address some tech debt, keep it as a Task and label it TechDebt. If it’s a bug and it doesn’t have immediate value to the end user, it likely will be awhile until Bug Grooming prioritizes it.

The tech debt wiki page?

Lets start transitioning the items into Tasks in Jira with the label TechDebt. Once an item in that page is in Jira, lets remove it from that page and if we like this process we’ll remove the page once it’s empty.

Uhm, what is this Platform component?

This component tends to become a dumping ground of everything that doesn’t fit somewhere else. Lets not add tech debt to it. In fact I’ve re-named this component to Architecture to better distinguish where we find our Architectural backlog. My goal is to add issues to, clean-up and prioritize it to fit its name so that there’s an up-to-date issue list to see our Architecture priorities and wishes. I’ll continue to flesh items out in this component and get them groomed through the feature grooming process.

Skip Roadmap!? What about acceptance criteria?

Yes we’re skipping the Roadmap status and going straight to ToDo. If we didn’t then we couldn’t use the same agile jira board to groom the tech debt backlog as the one that holds our sprint - adding overhead. I also think that generally we the developers know what the rough acceptance criteria for tech debt should be, enough so that we don’t need a fully formed ticket and a separate status to move through to ensure everyone’s on the same page - for prioritization at least. We will need that well formed Acceptance Criteria to estimate however, so don’t use it as an excuse to leave the juicy details out.

Is this the way of things now?

Yes. For Tech Debt. Lets take control of what is slowing development down the most and start fixing. I’ll be looking to step out of the way quickly once we get a good rhythm going.

Thoughts? Questions?

Best,

Josh

Josh Zamor

OpenLMIS Architect

josh.zamor@openlmis.org

SKYPE: josh.zamor.vr

OpenLMIS.org OpenLMIS Wiki

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/0D17CB45-B0D0-459F-8CF8-F22030D22AA7%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

HI all,

I really like that idea. In my opinion in the last few sprints we only added new features to the OpenLMIS and we forgot about TechDebt. The wiki page was good but there are too many positions and we don’t remove fixed debts. I only worry that after release we will add 20% of tech debts to sprints but after some time and near the next release we will don’t have time for that.

Regards,

Lukasz


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Thu, Apr 5, 2018 at 9:03 AM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Hi Josh,

I have two questions:

  1. How many Story Points every Sprint would be spent on fixing the tech debt? Would that be 20% of the Sprint capacity?
  2. Would the TechDebt backlog also include UI Tech Debts?
    Anyway, I really like the idea!

Best regards,
Nikodem

**
SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVWF0TiLxHEx_xET_3BKcRyYZxmARbwPqetE-bCS2xtSw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Thu, Apr 5, 2018 at 6:06 AM, Josh Zamor josh.zamor@villagereach.org wrote:

OpenLMIS Tech, lets take a moment to discuss our favorite topic: Tech Debt and how we address it.

To recap a few approaches we’ve tried:

  • We have a Technical Debt wiki page (which we don’t groom often enough - mea culpa)
  • We’ve turned them into Bugs (getting lost in the actual list of bugs)
  • We have/had a Component named Platform (which has everything from Tech Debt to future looking architecture)
  • We have/had a couple labels: TechDebt and TechBacklog (which I’ve transitioned so that we only now have TechDebt)

I think it’s fair to say that tech debt doesn’t always get prioritized, or the prioritization occurs too far removed from the developers whom have to live with the debt. To fix this I’d propose that we, the technical committee, start creating a cohesive tech debt backlog which we will groom for each sprint iteration knowing that we’ll always have a bucket of time set-aside to fix the technical issues that most need addressing.

To achieve this I propose we start with the following:

  1. Enter new TechDebt in Jira as a Task with the label TechDebt (it already exists and there’s a quick filter).
  • No Stories or improvements. Epics are okay.
  1. Transition the Task from Roadmap status straight to To Do.
  • We’re going to experiment with skipping Roadmap just for TechDebt.
  • This is not what we have in our Ticket Workflow , but we need to do this to use Jira grooming later.
  1. Once a sprint we, the developers and tech leads, will groom the TechDebt backlog by first prioritizing in the issue list, and then by ranking them on the board.
  • I’ll send out a meeting invite for sprint 51 to kick it off. Then perhaps we can move it to a slack channel.
  • Grooming the backlog is our responsibility and it won’t occur in the regular grooming sessions (which I think we should refer to as feature and bug grooming).
  1. As we start a new sprint, we’ll estimate w/ story points the top of our TechDebt backlog and place those into a dummy sprint we create named TechDebt Next.
  • I started this for Sprint 51, here’s a picture.
  • We’ll never start the Tech Debt Next dummy sprint, it’s just for organizing and grooming.
  1. We know we’ve estimated enough when the TechDebt Next sprint is roughly 20% of ourtotal estimated velocity.
  2. When our team’s next sprint is starting, we’ll pull items from the TechDebt Next sprint into our regular **Team’s Sprint. **
  • We can at this point delete the dummy sprint Tech Debt Next.
  1. During the sprint we can see which Jira issues are TechDebt with the Quick Filter Tech Debt.

Why a label?

We’re going to use a label as TechDebt can take a number of different forms, and we want a consistent way to find it.

How about Bugs?

Tech Debt could be a Bug, however I think more often than not a Bug should be kept as something that prevents an end-user from accomplishing a stated functionality of OpenLMIS. More importantly Bugs will be groomed and prioritized separately as they always have been. To control when we address some tech debt, keep it as a Task and label it TechDebt. If it’s a bug and it doesn’t have immediate value to the end user, it likely will be awhile until Bug Grooming prioritizes it.

The tech debt wiki page?

Lets start transitioning the items into Tasks in Jira with the label TechDebt. Once an item in that page is in Jira, lets remove it from that page and if we like this process we’ll remove the page once it’s empty.

Uhm, what is this Platform component?

This component tends to become a dumping ground of everything that doesn’t fit somewhere else. Lets not add tech debt to it. In fact I’ve re-named this component to Architecture to better distinguish where we find our Architectural backlog. My goal is to add issues to, clean-up and prioritize it to fit its name so that there’s an up-to-date issue list to see our Architecture priorities and wishes. I’ll continue to flesh items out in this component and get them groomed through the feature grooming process.

Skip Roadmap!? What about acceptance criteria?

Yes we’re skipping the Roadmap status and going straight to ToDo. If we didn’t then we couldn’t use the same agile jira board to groom the tech debt backlog as the one that holds our sprint - adding overhead. I also think that generally we the developers know what the rough acceptance criteria for tech debt should be, enough so that we don’t need a fully formed ticket and a separate status to move through to ensure everyone’s on the same page - for prioritization at least. We will need that well formed Acceptance Criteria to estimate however, so don’t use it as an excuse to leave the juicy details out.

Is this the way of things now?

Yes. For Tech Debt. Lets take control of what is slowing development down the most and start fixing. I’ll be looking to step out of the way quickly once we get a good rhythm going.

Thoughts? Questions?

Best,

Josh

Josh Zamor

OpenLMIS Architect

josh.zamor@openlmis.org

SKYPE: josh.zamor.vr

OpenLMIS.org OpenLMIS Wiki

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/0D17CB45-B0D0-459F-8CF8-F22030D22AA7%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Hello.

  I really like the idea of putting more focus on the tech debt (and bugs) and setting up reserved capacity to fix them during each sprint sounds like a good idea. The last few sprints were primarily focused on adding new features, to get as many of them as possible for 3.3, but at the same time the tech debt topic got a little neglected.

  The process you propose looks good. I was only wondering whether we really need the step of a dummy sprint creation. 20% of a sprint velocity is not really that much, we may end up with 3-5 tech debt tickets for the next sprint at max I guess. Maybe a separate label "TechDebt-Next" would be sufficient or even just a priority field.

Best regards,

  Sebastian.
···

On 05.04.2018 09:03, Nikodem Graczewski wrote:

Hi Josh,

    I have two questions:
  1.           How many Story Points every Sprint would be spent on fixing the tech debt? Would that be 20% of the Sprint capacity?
    
  2. Would the TechDebt backlog also include UI Tech Debts?
    Anyway, I really like the idea!

         Best regards,
    
         Nikodem
    

** Nikodem Graczewski

                               **
  •                                  Software Developer*
    

ngraczewski@soldevelo.com

      On Thu, Apr 5, 2018 at 6:06 AM, Josh Zamor <josh.zamor@villagereach.org>
      wrote:
          OpenLMIS Tech, lets take a moment to discuss our favorite topic:  Tech Debt and how we address it.

To recap a few approaches we’ve tried:

  • We have a Technical Debt wiki page (which we don’t groom often enough - mea culpa)
  •                 We’ve turned them into Bugs (getting lost in the actual list of bugs)
    
  •                 We have/had a Component named Platform (which has everything from Tech Debt to future looking architecture)
    
  •                 We have/had a couple labels:  TechDebt and TechBacklog (which I’ve transitioned so that we only now have TechDebt)
    
            I think it’s fair to say that tech debt doesn’t always get prioritized, or the prioritization occurs too far removed from the developers whom have to live with the debt.  To fix this I’d propose that we, the technical committee, start creating a cohesive tech debt backlog which **we will groom** for each sprint iteration knowing that we’ll [always have a bucket of time set-aside](https://www.atlassian.com/blog/jira-software/groom-backlog-like-boss-jira-software)                 to fix the technical issues that most need addressing.
            To achieve this I propose we start with the following:
  1. Enter new TechDebt in Jira as a Task with the label TechDebt (it already exists and there’s a quick filter).
  • No Stories or improvements. Epics are okay.
  1.                 Transition the Task from Roadmap status straight to **To Do**.
    
  •                     We’re going to experiment with skipping Roadmap just for TechDebt.
    
  • This is not what we have in our Ticket Workflow , but we need to do this to use Jira grooming later.
  1. Once a sprint we, the developers and tech leads , will groom the TechDebt backlog by first prioritizing in the issue list , and then by ranking them on the board.
  •                     I’ll send out a meeting invite for sprint 51 to kick it off.  Then perhaps we can move it to a slack channel.
    
  •                     Grooming the backlog is our responsibility and it won’t occur in the regular grooming sessions (which I think we should refer to as feature and bug grooming).
    
  1. As we start a new sprint, we’ll ** estimate w/ story points** the top of our TechDebt backlog and place those into a dummy sprint we create named TechDebt Next.
  • I started this for Sprint 51, here’s a picture.
  •                     We’ll never start the Tech Debt Next dummy sprint, it’s just for organizing and grooming.
    
  1. We know we’ve estimated enough when the ** TechDebt Next sprint is roughly 20%** of our** total estimated velocity**.
  2.                 When our team’s next sprint is starting, we’ll pull items from the TechDebt Next sprint into our regular **Team’s Sprint.  **
    
  •                     We can at this point delete the dummy sprint Tech Debt Next.
    
  1.                 During the sprint we can see which Jira issues are TechDebt with the Quick Filter [Tech Debt](https://openlmis.atlassian.net/secure/RapidBoard.jspa?rapidView=46&projectKey=OLMIS&quickFilter=186).
    

Why a label?

            We’re going to use a label as TechDebt can take a number of different forms, and we want a consistent way to find it.

How about Bugs?

            Tech Debt could be a Bug, however I think more often than not a Bug should be kept as something that **                  prevents an end-user from accomplishing a stated functionality** of OpenLMIS.  More importantly Bugs will be groomed and prioritized separately as they always have been.  To control when we address some tech debt, keep it as a Task and label it TechDebt.  If it’s a bug and it doesn’t have immediate value to the end user, it likely will be awhile until Bug Grooming prioritizes it.

The tech debt wiki page?

Lets start transitioning the items into Tasks in Jira with the label TechDebt. Once an item in that page is in Jira, lets remove it from that page and if we like this process we’ll remove the page once it’s empty.

Uhm, what is this Platform component?

This component tends to become a dumping ground of everything that doesn’t fit somewhere else. Lets not add tech debt to it. In fact I’ve re-named this component to Architecture to better distinguish where we find our Architectural backlog. My goal is to add issues to, clean-up and prioritize it to fit its name so that there’s an up-to-date issue list to see our Architecture priorities and wishes. I’ll continue to flesh items out in this component and get them groomed through the feature grooming process.

Skip Roadmap!? What about acceptance criteria?

            Yes we’re skipping the Roadmap status and going straight to ToDo.  If we didn’t then we couldn’t use the same agile jira board to groom the tech debt backlog as the one that holds our sprint - adding overhead.  I also think that generally we the developers know what the rough acceptance criteria for tech debt should be, enough so that we don’t need a fully formed ticket and a separate status to move through to ensure everyone’s on the same page - for prioritization at least.  We will need that well formed Acceptance Criteria to estimate however, so don’t use it as an excuse to leave the juicy details out.

Is this the way of things now?

            Yes.  For Tech Debt.  Lets take control of what is slowing development down the most and start fixing.  I’ll be looking to step out of the way quickly once we get a good rhythm going.

Thoughts? Questions?

Best,

Josh

Josh Zamor

                OpenLMIS Architect

                josh.zamor@openlmis.org  

                SKYPE: josh.zamor.vr 

                [OpenLMIS.org](https://openlmis.org)  [                          OpenLMIS Wiki](https://openlmis.atlassian.net/wiki/display/OP/OpenLMIS+Wiki%3A+Home)
            --

            You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

            To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

            To post to this group, send email to openlmis-dev@googlegroups.com.

            To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/0D17CB45-B0D0-459F-8CF8-F22030D22AA7%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/0D17CB45-B0D0-459F-8CF8-F22030D22AA7%40villagereach.org?utm_medium=email&utm_source=footer).

            For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
  **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

      SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

    Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

    Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

  --

  You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

  To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

  To post to this group, send email to openlmis-dev@googlegroups.com.

  To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVWF0TiLxHEx_xET_3BKcRyYZxmARbwPqetE-bCS2xtSw%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVWF0TiLxHEx_xET_3BKcRyYZxmARbwPqetE-bCS2xtSw%40mail.gmail.com?utm_medium=email&utm_source=footer).

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).


Sebastian Brudziński

              Senior Software Developer / Team Leader


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
sbrudzinski@soldevelo.com

Hi,

Nikodem, yes it would be in story points and roughly 20% of what you think you’ll get done. So if last sprint you complete 100 story points, and you don’t see any reason to not get another 100 story points done in the upcoming sprint, add roughly 20 story points of tickets into Tech Debt Next. And also it’d include the Web UI Tech Debt.

Lukasz, agreed we’ll have to be good about keeping with the plan. That said I do think it’ll be an ongoing balancing act. Some sprints we may all agree that we need to go higher than 20% on tech debt, or in others that we need to go lower - to focus on bugs perhaps. We’ll start with roughly 20% and see how we do.

Sebastian, no I guess we don’t technically need the dummy sprint Tech Debt Next, you’re right. However by using it I hope we accomplish two things: we start to learn how to groom visually in Jira (instead of confluence) and we all know just the handful of useful Jira Issue filters that help us get a handle on roughly prioritizing various backlogs (feature, bug, techdebt). Lets start by trying it and then we can discuss.

Thanks all, glad we’re seeing the same issues.

Best,

Josh

···

On 05.04.2018 09:03, Nikodem Graczewski wrote:

Hi Josh,

I have two questions:

  1. How many Story Points every Sprint would be spent on fixing the tech debt? Would that be 20% of the Sprint capacity?
  2. Would the TechDebt backlog also include UI Tech Debts?
    Anyway, I really like the idea!

Best regards,

Nikodem

**Nikodem Graczewski
**

Software Developer

ngraczewski@soldevelo.com

On Thu, Apr 5, 2018 at 6:06 AM, Josh Zamor
josh.zamor@villagereach.org wrote:

OpenLMIS Tech, lets take a moment to discuss our favorite topic: Tech Debt and how we address it.

To recap a few approaches we’ve tried:

  • We have a Technical Debt wiki page (which we don’t groom often enough - mea culpa)
  • We’ve turned them into Bugs (getting lost in the actual list of bugs)
  • We have/had a Component named Platform (which has everything from Tech Debt to future looking architecture)
  • We have/had a couple labels: TechDebt and TechBacklog (which I’ve transitioned so that we only now have TechDebt)

I think it’s fair to say that tech debt doesn’t always get prioritized, or the prioritization occurs too far removed from the developers whom have to live with the debt. To fix this I’d propose that we, the technical committee, start creating a cohesive tech debt backlog which we will groom for each sprint iteration knowing that we’ll always have a bucket of time set-aside to fix the technical issues that most need addressing.

To achieve this I propose we start with the following:

  1. Enter new TechDebt in Jira as a Task with the label TechDebt (it already exists and there’s a quick filter).
  • No Stories or improvements. Epics are okay.
  1. Transition the Task from Roadmap status straight to To Do.
  • We’re going to experiment with skipping Roadmap just for TechDebt.
  • This is not what we have in our Ticket Workflow , but we need to do this to use Jira grooming later.
  1. Once a sprint we, the developers and tech leads, will groom the TechDebt backlog by first prioritizing in the issue list, and then by ranking them on the board.
  • I’ll send out a meeting invite for sprint 51 to kick it off. Then perhaps we can move it to a slack channel.
  • Grooming the backlog is our responsibility and it won’t occur in the regular grooming sessions (which I think we should refer to as feature and bug grooming).
  1. As we start a new sprint, we’ll estimate w/ story points the top of our TechDebt backlog and place those into a dummy sprint we create named TechDebt Next.
  • I started this for Sprint 51, here’s a picture.
  • We’ll never start the Tech Debt Next dummy sprint, it’s just for organizing and grooming.
  1. We know we’ve estimated enough when the TechDebt Next sprint is roughly 20% of ourtotal estimated velocity.
  2. When our team’s next sprint is starting, we’ll pull items from the TechDebt Next sprint into our regular **Team’s Sprint. **
  • We can at this point delete the dummy sprint Tech Debt Next.
  1. During the sprint we can see which Jira issues are TechDebt with the Quick Filter Tech Debt.

Why a label?

We’re going to use a label as TechDebt can take a number of different forms, and we want a consistent way to find it.

How about Bugs?

Tech Debt could be a Bug, however I think more often than not a Bug should be kept as something that prevents an end-user from accomplishing a stated functionality of OpenLMIS. More importantly Bugs will be groomed and prioritized separately as they always have been. To control when we address some tech debt, keep it as a Task and label it TechDebt. If it’s a bug and it doesn’t have immediate value to the end user, it likely will be awhile until Bug Grooming prioritizes it.

The tech debt wiki page?

Lets start transitioning the items into Tasks in Jira with the label TechDebt. Once an item in that page is in Jira, lets remove it from that page and if we like this process we’ll remove the page once it’s empty.

Uhm, what is this Platform component?

This component tends to become a dumping ground of everything that doesn’t fit somewhere else. Lets not add tech debt to it. In fact I’ve re-named this component to Architecture to better distinguish where we find our Architectural backlog. My goal is to add issues to, clean-up and prioritize it to fit its name so that there’s an up-to-date issue list to see our Architecture priorities and wishes. I’ll continue to flesh items out in this component and get them groomed through the feature grooming process.

Skip Roadmap!? What about acceptance criteria?

Yes we’re skipping the Roadmap status and going straight to ToDo. If we didn’t then we couldn’t use the same agile jira board to groom the tech debt backlog as the one that holds our sprint - adding overhead. I also think that generally we the developers know what the rough acceptance criteria for tech debt should be, enough so that we don’t need a fully formed ticket and a separate status to move through to ensure everyone’s on the same page - for prioritization at least. We will need that well formed Acceptance Criteria to estimate however, so don’t use it as an excuse to leave the juicy details out.

Is this the way of things now?

Yes. For Tech Debt. Lets take control of what is slowing development down the most and start fixing. I’ll be looking to step out of the way quickly once we get a good rhythm going.

Thoughts? Questions?

Best,

Josh

Josh Zamor

OpenLMIS Architect

josh.zamor@openlmis.org

SKYPE: josh.zamor.vr

OpenLMIS.org OpenLMIS Wiki

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/0D17CB45-B0D0-459F-8CF8-F22030D22AA7%40villagereach.org
.

For more options, visit
https://groups.google.com/d/optout
.

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax:
+48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVWF0TiLxHEx_xET_3BKcRyYZxmARbwPqetE-bCS2xtSw%40mail.gmail.com
.

For more options, visit
https://groups.google.com/d/optout
.


Sebastian Brudziński

Senior Software Developer / Team Leader

sbrudzinski@soldevelo.com