Best practise for covering unit test development of existing code

It’s up to the team to decide. Do you think it sounds like a credible user story though?Why not just include a criterion in the Definition of Done to increase code coverage by a certain percentage each Sprint increment?

Hi Matt - I often talk with teams that inherit an existing product, which has no test coverage.  This is simply technical debt that must be paid back over time.  I agree with Ian's point about the Definition of Done - a good step to take

What I also see as an additional, effective technique is to make all of the technical debt transparent to your Product Owner, helping them understand how technical debt negatively impact team health (who wants to work in such a code base - developers may leave), slows the output of the Development Team, and adds to quality problems due to lack of automation.  Then come up with a working agreement in each Sprint Planning session between the Product Owner and Development Team as to how much of the technical debt will be paid back (e.g let's reserve 10% of capacity to write missing unit tests).  You don't have to write user stories for this.

Chris

Hey there,

I agree with Ian when he says "include a criterion in the Definition of Done to increase code coverage by a certain percentage each Sprint incremen", do that and than let the team decide what the best way to complete this DOD. I worked at the same way in a team in 2018 when our DOD was something like "coverage must be at 90%" so every retrospective we see our Coverage indicator and if its bellow 90% we put a item in our backlog to "ajust" that.

Now in my experience the point here is not the tecnical part of doing de coverage, I really belive that you team can do this, but the point here(that i had troubles) is how we convince the user, client, PO and etc to spend time(or money) in coverage tests.

And the answer for me when this happened in my team was saying that every sprint they will have a increment with quality, so my client/user/PO was comfortable enough to let the team do Spikes, Devops Automation or any technical thing that does not affect the user/client directly(like a new front, or functionality).

This was the trick for me here when I had the same situation in my work, change the mindset,and it did not work at the first time, I needed to be very insistent and resilient to let the they comfortable with that.

As everyone has said, you are asking the age old question of how to deal with technical debt.  And true to Scrum, all of have seen/done this many ways and you will always get answer of "the team needs to decide the right way to handle it".  That is absolutely the best answer you can get. 

Should I just reserve some time and not bring as many stories into the sprint during planning so that we have some time available - but not specifically call it out?

If you read the Scrum Guide correctly it there is no one that can make that call.  There is nothing in the guide that mentions limiting the number of stories included in Sprint Planning.  It just says that the Sprint Backlog is created from Product Backlog items. It discusses how PBIs should be refined enough that the Development Team can agree it can be completed in a single sprint. There is also mention that the Development Team controls what constitutes the Sprint Backlog.  

I'll you go and ahead give you a suggestion for how I approach it so that you can have one more perspective.  Facilitate the entire SCRUM Team in a discussion about it.  Help the PO understand that Technical Debt actually has 2 values, negative if you ignore it and positive if you fix it.  Then working with the PO, introduce stories into the Product Backlog. The PO is responsible for ordering the PBIs in a way that ensures the Dev Team is providing the needed value and everyone should honor that.  If they don't have stories or understand the value derived, then they will always order new ideas above technical debt. Transparency is key.  And in every case, the Scrum Teams have decided how they want to handle this.