Recently I started a new project at work (it was nice to shake off the cruft of an old project and pick up a new one) and my team and I are pushing harder for more professional development practices, which include writing Unit Tests. The Product Owner isn't so impressed since this translates into delayed feature delivery, in the PO's opinion.

The PO (who is also my boss's boss, which provides a bit of conflict of interest IMO) is very upset about an issue that slipped through to our release product. I'm making the point that a good Unit Test suite would have caught the issue (some additional refactoring needed to deal with some inexperienced coder's architecture blunders), and the PO wasted no time in suggesting that we "figure out how to spend some quality OT on setting up unit tests then." Our schedule is already packed with feature requests and minimal time for bug fixing and other maintenance tasks required.

I'm disinclined to offer overtime for something that I've come to learn is to be included as part of the standard development process in a team of professionals. How do I communicate that Unit Test writing is a necessary part of the day-to-day responsibility of the developer? How can I help guard my team from being demotivated by having overtime demanded of them?

PS, I don't know how to tag this, I'd appreciate any help with that, too.

  • 1
    I'm not familiar with the term "Product Owner". Is this your customer? – David K Jul 8 '15 at 14:09
  • 1
    Possibly related as it addresses one aspect of the problem: workplace.stackexchange.com/questions/7095/… – 404usernotfound Jul 8 '15 at 14:11
  • @DavidK Yes! Sorry for the ambiguity. This is to refer to the person who own the product my team is developing. – Hyperbole Jul 8 '15 at 14:15
  • @404usernotfound I'm not a contractor, I'm not sure your link helps (though it's a good read, thanks). – Hyperbole Jul 8 '15 at 14:16
  • @JoeStrazzere I'm a team lead, and I'm speaking for myself. I'd like to be able to prevent others from also having to put in overtime, too, since protecting my team is a part of my job (that I enjoy, even). – Hyperbole Jul 8 '15 at 17:17

Since you are using the term Product Owner, I'm going to assume you're using Scrum (or a related method). If not, ignore this answer completely.

If you are using scrum, the PO doesn't determine how much the team can do in a sprint, the team does. If you need unit tests to help you meet the PO's definition of done, then include them in your point estimates. In scrum, your schedule shouldn't be "packed" -- you can only get so many points done each sprint, and that's your schedule.

The PO should be setting the priority based on business value gained. If bug fixes and technical debt aren't important to the PO, then they won't put them high on the priority list. But your team should not be held liable for them either. If the work met the PO's definition of done (and QA testing should be included in the definition of done), then you did what was required.

Your Scrum Master should be the one guarding the team from both interference by the PO and interference from higher ups, so get them involved.

  • The PO's definition of Done has been negotiated to indicate "development completed but with QA," against my better judgement. – Hyperbole Jul 8 '15 at 15:31
  • 7
    Then your Scrum Master needs to make sure it's the PO, not the team, who is held accountable for that decision. – Kathy Jul 8 '15 at 15:53
  • @Kathy has the right idea. OP you have to educate your boss on why unit testing is important for him to agree. Right now he doesn't seem to understand the value of it, the best way to do that is to do his approach and when tech debt piles up mention to him that it is because you guys are not doing unit testing. He will then be more likely to listen. – bobo2000 May 25 '16 at 9:21

When you scope or size your features do you break down unit testing as part of that or is it a separate line item? I would suggest that you make unit testing part of your development process and then scope tasks accordingly, while not breaking them down into code this feature test this feature. Just assume that the effort to "code" a feature includes writing the test cases.

If asked why things are being scoped higher, just indicate the project is growing, the larger the project the more features cost to add. You could enlighten him on TDD (test driven development), but I don't think it will make much difference. On the other hand if TDD is part of your development process, then it's just all integrated and isn't really a separate thing, it is just how you get things done.

If you are doing agile/scrum then the PO shouldn't be dictating schedule anyway, he/she should just priority and defining features. It's your team's job to give him a timeline. If you have to go back and do some cleanup then there is some argument for own time, but you may want to negotiate a certain amount of "Engineering" time. Where I work now we have a negotiated that 15% of our time is dedicated to engineering efforts. These are things we have identified internally as needing fixed. It could be a performance thing that isn't too noticeable now, but will be soon, or it could be that module that was not done right the first time and needs some love.

  • Making UT a line item in a task is a practical risk, the PO is highly resistant to anything that doesn't have an immediate, tangible business benefit. Even after this major defect in a published product, the benefits of UTs aren't something the PO is willing to hear. – Hyperbole Jul 8 '15 at 15:28
  • 1
    You said 'development done' was part of your definition of done. UT is part of development, it is developer written test cases and should be part of your definition of development, assuming have a definition for that. You may need to push this if you want this incorporated, so it's not done or even ready for QA until all the unit tests pass. It's also code, your PO clearly doesn't understand software development, so good luck. – Bill Leeper Jul 8 '15 at 21:05

Your Answer

