Skip to main content

The "Negotiate" of I.N.V.E.S.T. - How much and when?

Last post 11:42 pm March 29, 2021 by Garrie Irons
3 replies
08:42 pm March 23, 2021

Scrum practitioners:

What is your experience with the degree and the right time to "negotiate" on a story?  Is this done purely during PBR, and when a Sprint begins, the story becomes"fixed?"  (Even though it's not supposed to be "a contract?")  Or during development, as collaboration occurs, does "negotiation" also occur?  I'm sure there are risks to being too strict either way....

If you allow "too much" negotiation during the sprint and are always negotiating about what can or can't be accomplished, it could be that:

  • things (stories) just never get done because the goals are constantly being re-negotiated 
  • metrics are all screwed up and capacity and velocity are meaningless
  • therefore, estimating becomes meaningless
  • no one feels accountable to accomplish goals
  • no one is held accountable to accomplish goals
  • the team is engaging in an anti-pattern and isn't holding themselves / each other accountable
  • project goals aren't reached in a reasonable time
  • and ultimately value isn't delivered. 

If you force all negotiation to occur in PBR before a story is accepted into a Sprint, then it could be that:

  • collaboration is forsaken in order to get this agreed-upon story done (just git 'er done!)
  • the sprint builds something that is wasted because the opportunity to refine the goal was missed
  • findings are not brought back to the PO to inform refinement of other stories

It seems to me that a rule of thumb would be to fix the stories in advance of the sprint (negotiate ahead of time, during PBR), accept the risk of "waste" during the sprint (a story may be produced that is ultimately discarded b/c, as we later learn, it did not provide value), but also force (foster) collaboration during the sprint to bring the learnings into future PBR.

Has anyone else encountered this balancing act?  Either too much negotiation during the sprint and always moving the goal posts?  Or too little allowance for negotiation during the sprint and creating too much churn and too much waste?   Has anyone else fell off this tightrope and have the bruising and scars to show for it?

What are your lessons learned for when and how much to negotiate?  

Thanks in advance.  And if I missed them, please point me to other forum entries where this topic may have been discussed before! 


11:49 pm March 23, 2021

A user story is a placeholder for a conversation about a potential requirement. If it isn't Done yet, why would the conversation stop?

06:45 pm March 24, 2021

Ian, that's a insightful question.  It triggers three followups for me:

1) If the story is just a placeholder, what do the metrics mean (if anything?) as story points are estimated in sprint planning, as burndown is calculated during the sprint, and velocity is measures over time across many sprints? 

2) The conversation should never stop, of course - that's what the collaboration is during the sprint.  But I have seen negotiation take the place of collaboration and conversation, where the development team is negotiating down to what they've already done and the owner still has an outstanding need with insufficient value delivered.  What's a Scrum Master to do in these cases?

3) If a story is accepted into a sprint backlog, hasn't it moved from the "potential" to the "real?"  That is, shouldn't the user (owner) have matured their story enough for the team to act on it?


11:42 pm March 29, 2021

3) If a story is accepted into a sprint backlog, hasn't it moved from the "potential" to the "real?"  That is, shouldn't the user (owner) have matured their story enough for the team to act on it?

The PBI's should leave implementation to the dev team.

"As a user I want to have private text chats, public text chats, voice chats and video chats"

Dev team: text chats - 5 points either way. Voice chats: 25 points. Video chats: 100 points.

Dev team: tight integration with Skype/Teams/Google Meet/... that "looks to the user" like they didn't leave our product. 10 points.

If the dev team implement PBI's without a conversation between "accepting the PBI" and "releasing the PBI" then you've set up small units of waterfall release. That's fine but it is prescriptive work not adaptive work.

I'm not a fan of velocity: I'm a fan of meeting sprint goals and realising product vision. Velocity is an indicator of prescriptiveness over learning.


IMO no PBI as much as the Sprint Goal which has been identified as a collective representation of a set of PBI's. The sum is greater than the parts.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.