6

Introduction: In theory, Scrum says that the development team is fully responsible and self-organized when it comes to all things related to development. This also includes code quality which imho is a result of CI, automated testing and more.

Scenario: A Scrum Product Owner is responsible for some software product. The quality lately decreased due to increasing complexity.

Question: How can the Scrum Product Owner influence the development in a way that they look more into quality? Items in the product backlog are features that have direct customer value. Code quality only has indirect customer value. Can the Product Owner force the dev team to increase quality, e.g. by using CI, more/better automated tests, ... ?

Improve this question
2
  • 1
    You can collaborate with the team to define a Definition of Done that produces increments of higher quality. You may need to define user stories that focus on team infrastructure rather than product features to make capacity available for it within the sprints.
    – Todd A. Jacobs ♦
    Commented May 31, 2016 at 2:40
  • Is the external, visibility quality decreasing? That is, are the amount of issues in delivered products (both the software and any associated documentation products) increasing? Or is the problem simply in the quality of the written code in factors such as readability, maintainability, testability, etc.?
    – Thomas Owens ♦
    Commented May 31, 2016 at 13:37

3 Answers 3

Reset to default
8

The Product Owner has responsibility for the backlog and the development team has responsibility for delivery. However, in Scrum we work as a team and there is nothing to stop the Product Owner discussing concerns over delivery with the development team. Just as there is nothing to stop the development team discussing concerns over the backlog with the Product Owner. We favour collaboration over contract negotiation.

In your situation, the key is to try and influence the development team to improve their code quality rather than forcing them to do it.

I would suggest some or all of the following:

  • Highlight the impact quality is having on the customers.
  • If possible, quantify the cost (e.g. "we failed to land a customer worth 10k due to concerns over quality").
  • Emphasise that quality is a priority to you and that you are willing to accept delays in delivering functionality if the quality is high. Sometimes the development team assumes that delivering functionality is the highest priority.
  • Explore the reasons why the development team is not focusing on quality. Perhaps they lack experience or perhaps they feel under time pressure to deliver?
  • Forumulate user stories that encourage quality.

Forcing the development team to do something may work in the short term, but there is a danger they will just slip back in to old patterns of behaviour. A better approach is to get the development team to value quality as highly as you do.

Improve this answer
1

The product owner can add anything they like to the backlog.

Ie.

Setup a CI build server

Add unit tests untill you have 90% code coverage

However, the business justification for these things is pretty vague and revolves around the productivity of the dev team.

If the team isnt already doing these things in a 'sprint zero' they need either some training or some time to get it done.

Although you can apply scrum to 'project : setup a dev team' generaly its assumed you have a team and they have the tools computers, software licences, desks, an office etc they need to start work on 'project : write me a program'.

These days an automated dev ops enviroment with various enviroments, source control, unit tests and a ci build server should be considered part of that tool set.

Improve this answer
4
  • I disagree with the idea of writing development focused stories. In User Stories Applied Mike Cohn argues strongly (and in my opinion quite convincingly) for keeping stories limited to defining end user value.
    – CBRF23
    Commented May 31, 2016 at 9:47
  • I tend to agree. However its kinda vague, say im delievering a system which will be maintained by the customer going forward they might well have 'use TFS for source control' style requirements.
    – Ewan
    Commented May 31, 2016 at 12:41
  • Yes, very true - in that case, since it's a requirement of the customer and represents value to the customer, I would say it's a good story. However, if your customer was just going to be on subscription, it would not be a good story, as they just want working product, and could probably care less wether you use TFS or GIT or whatever to manage source code. I think part of being a good product owner is being able to make these types of judgment calls, and having a good team of developers to call your sh*t when you mess up :)
    – CBRF23
    Commented May 31, 2016 at 13:28
  • Also, I do agree with your assertion the product owner can add anything they like to the backlog. Part of the INVEST acronym is "negotiable" and that's where a good team will help you to weed out or improve bad stories :)
    – CBRF23
    Commented May 31, 2016 at 13:29
1

I would be interested to know what you mean by quality. Bugs, or something else?

If the concerns are related to quality that is visible to the end user, than I would focus on what you, as the product owner, can do to better define the acceptance criteria for your stories so as to preclude the problems you are having from being accepted.

Your role, as the Product Owner, is to give clear direction and provide continuous feedback on work completed. Make sure you and your team are communicating regularly about your goals and about story acceptance criteria, and make sure you are providing good direction and honest feedback on completed work. Make sure your team understands that they should be coming to you regularly to discuss any questions with execution and to clarify any ambiguity in stories/tasks. Make sure you make yourself available to them to listen to and answer these questions.

More specifically, here are a couple of ways to deal with different "quality" issues:

If it's bugs, work on your definition of done to ensure features are properly tested - including regression testing as they are integrated. Work on your own story writing skills and how you define up front and communicate the acceptance tests for your stories. Finally, if the requirements for testing and integration are clear, and the Definton of Done precludes buggy code from being accepted, and the team is failing to achieve this, then discuss the problem with your team at the next retrospective, and work with them to address it. Also, make sure you utilize your Scrum Master, who should be trying to figure out what's impeding the teams' ability to properly test the work done during an iteration.

If what you mean by a quality problem is not bugs, but something else, such as a request for information taking too long to execute, or a user interface that is not cohesive between screens, or something of that nature, here are a few tips for handling these types of problems:

First, again focus on developing a better DOD and better defining acceptance tests during backlog grooming and sprint planning. Also, work with your Scrum Master to ensure the team fully understands their responsibilities. If something is ambiguous or unclear, the developers are responsible for getting with the Product Owner or Customer to discuss and clarify. Ideally, everything is clarified during Sprint planning, but this might not always be the case, and it's important the developers know thy are responsible for clarifying the requirements and acceptance criteria for a story or task by discussing it with the PO (or directly with the Customer/end-user).

Second, if this functionality already exists (e.g. was part of an earlier story that was already accepted) and you're just not happy with the execution, then simply create another story to further clarify what it is you want. E.g. If requests take too long to return information, then write a story "I want X to happen quickly" and then follow the advice above to work with your team to clarify what will be acceptable for satisfying "quickly." Or if the issue is with user interface, write a story "The user interface should be consistent when switching screens." Again, clarification of either would ideally take place during Sprint planning or backlog grooming, as the team asks questions to estimate the story or as they start breaking it down into tasks to execute.

Finally, remember you are a team, and remember you meet regularly to discuss and improve your process. If you think the team would benefit from continuous integration, or pair programming, or some other development tool or strategy - I would suggest it during a retrospective as something that might be worth trying. Ultimately though, it is up to the development team to decide how they want to develop. As the PO you are responsible for setting the requirements for the end user, and the team is responsible for developing the solutions to said requirements.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.