Mixing
Product Owner demanding overtime for writing Unit Tests. How can I address this?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
9
down vote
favorite
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.
project-management time-management overtime
edited Jul 8 '15 at 22:40
mcknz
15.6k55468
asked Jul 8 '15 at 14:05
Hyperbole
1514
 |Â
show 5 more comments
up vote
9
down vote
favorite
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.
project-management time-management overtime
edited Jul 8 '15 at 22:40
mcknz
15.6k55468
asked Jul 8 '15 at 14:05
Hyperbole
1514
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
 |Â
show 5 more comments
up vote
9
down vote
favorite
up vote
9
down vote
favorite
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.
project-management time-management overtime
edited Jul 8 '15 at 22:40
mcknz
15.6k55468
asked Jul 8 '15 at 14:05
Hyperbole
1514
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.
project-management time-management overtime
edited Jul 8 '15 at 22:40
mcknz
15.6k55468
asked Jul 8 '15 at 14:05
Hyperbole
1514
edited Jul 8 '15 at 22:40
mcknz
15.6k55468
edited Jul 8 '15 at 22:40
mcknz
15.6k55468
edited Jul 8 '15 at 22:40
mcknz
15.6k55468
15.6k55468
asked Jul 8 '15 at 14:05
Hyperbole
1514
asked Jul 8 '15 at 14:05
Hyperbole
1514
asked Jul 8 '15 at 14:05
Hyperbole
1514
1514
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
 |Â
show 5 more comments
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
1
1
I'm not familiar with the term "Product Owner". Is this your customer?
– David K
Jul 8 '15 at 14:09
I'm not familiar with the term "Product Owner". Is this your customer?
– David K
Jul 8 '15 at 14:09
1
1
Possibly related as it addresses one aspect of the problem: workplace.stackexchange.com/questions/7095/…
– 404usernotfound
Jul 8 '15 at 14:11
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
@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
@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
@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
 |Â
show 5 more comments
2 Answers
2
active
oldest
votes
up vote
11
down vote
accepted
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.
answered Jul 8 '15 at 14:18
Kathy
1,886816
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
suggest improvements |Â
up vote
5
down vote
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.
edited Jul 8 '15 at 15:34
Canadian Luke
70611022
answered Jul 8 '15 at 14:15
Bill Leeper
10.7k2735
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
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
accepted
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.
answered Jul 8 '15 at 14:18
Kathy
1,886816
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
suggest improvements |Â
up vote
11
down vote
accepted
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.
answered Jul 8 '15 at 14:18
Kathy
1,886816
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
suggest improvements |Â
up vote
11
down vote
accepted
up vote
11
down vote
accepted
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.
answered Jul 8 '15 at 14:18
Kathy
1,886816
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.
answered Jul 8 '15 at 14:18
Kathy
1,886816
answered Jul 8 '15 at 14:18
Kathy
1,886816
answered Jul 8 '15 at 14:18
Kathy
1,886816
answered Jul 8 '15 at 14:18
Kathy
1,886816
1,886816
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
suggest improvements |Â
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
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
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
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
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
@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
suggest improvements |Â
up vote
5
down vote
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.
edited Jul 8 '15 at 15:34
Canadian Luke
70611022
answered Jul 8 '15 at 14:15
Bill Leeper
10.7k2735
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
suggest improvements |Â
up vote
5
down vote
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.
edited Jul 8 '15 at 15:34
Canadian Luke
70611022
answered Jul 8 '15 at 14:15
Bill Leeper
10.7k2735
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
suggest improvements |Â
up vote
5
down vote
up vote
5
down vote
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.
edited Jul 8 '15 at 15:34
Canadian Luke
70611022
answered Jul 8 '15 at 14:15
Bill Leeper
10.7k2735
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.
edited Jul 8 '15 at 15:34
Canadian Luke
70611022
answered Jul 8 '15 at 14:15
Bill Leeper
10.7k2735
edited Jul 8 '15 at 15:34
Canadian Luke
70611022
edited Jul 8 '15 at 15:34
Canadian Luke
70611022
edited Jul 8 '15 at 15:34
Canadian Luke
70611022
70611022
answered Jul 8 '15 at 14:15
Bill Leeper
10.7k2735
answered Jul 8 '15 at 14:15
Bill Leeper
10.7k2735
answered Jul 8 '15 at 14:15
Bill Leeper
10.7k2735
10.7k2735
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
suggest improvements |Â
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
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
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
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
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
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f49393%2fproduct-owner-demanding-overtime-for-writing-unit-tests-how-can-i-address-this%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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