2

Let's say a Product Owner who approves all work before it goes to production, writes the requirements as X.

The Team Lead (senior developer) who approves all code changes says do Y, which is contradictory to X.

How do you resolve contradictory directions between two people, both of which have authority over a project?

Improve this question
2
  • 1
    Have you pointed out to either of them that there is a contradiction in requirements?
    – sf02
    Commented Aug 21, 2020 at 18:42
  • 5
    Are these technical requirements or functional requirements? The product owner is responsible for what the product does, the team lead is responsible for how it does it.
    – Evan M
    Commented Aug 21, 2020 at 18:51

2 Answers 2

Reset to default
13

This is a case where you first get the two of them in a room, and let them hash it out.

In an Agile workflow, the product owner defines the requirements. The team lead has a voice while the story is being groomed (as should all team members), but once the story is in the sprint the requirements should not change.

If the two of them cannot come to an agreement\understanding, bring it up with your manager, as this may be an issue you cannot resolve yourself.

At the moment though, it appears your team lead needs to be reminded that the product owner defines the requirements and it is up to the team as a whole to make it happen (implement).

Note: If there is a technical reason that a requirement may need to change, that should be discussed with the product owner before coding.

Improve this answer
8
  • It's possible in Scrum for requirements to change during a sprint as a result of things learned during the sprint, and it's not neccesarily a bad thing either.
    – Erik
    Commented Aug 23, 2020 at 15:09
  • 2
    @Erik agreed as an exception and not the norm.
    – Neo
    Commented Aug 23, 2020 at 15:49
  • @Erik by definition you want the requirements for the items that are going to be created during the sprint to be set in stone, otherwise those requirements are not yet understood well enough for this item to be taken on in a sprint. One of the main points in scrum is that everything is fluid right up until the sprint so that you can be reasonably sure that you're actually able to deliver an increment that adheres to the requirements. If the requirements change, you need to re-evaluate whether or not you will be able to meet them, which takes time away from creating the increment.
    – Cronax
    Commented Aug 24, 2020 at 14:35
  • @Cronax No you don't. If something weird happens and you have to chose between changing the requirements and building the wrong thing, you want to change the requirements. Like Neo says, it should be an exception, but it's still better than the alternative when it happens.
    – Erik
    Commented Aug 24, 2020 at 14:42
  • @Erik I'm saying that you don't want that to be standard operating procedure because at that point you'll never be sure whether or not you can actually deliver a sprint. I would in fact argue that rather than just taking the changing requirements in stride, the desired procedure would be to completely stop the sprint and if the feature is still the most important and appropriate way to add value, to refine it sufficiently and then start a new sprint. The team commits to the sprint backlog, when you change the requirements then you're no longer doing what you committed to.
    – Cronax
    Commented Aug 24, 2020 at 14:48
-1

You do what your team lead says. You point it out to him, but at the end there is a chain of command, and you are on a team and he is the team lead and as long as you can point out that you did raise the issue - it is his job, his responsibility and thus also his failure.

Note that check in comments are a great and non-changeable place to point out how this change contradicts requirements by the product owner but is demanded by team lead.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .