Posted on 2 Comments

“Accepting the work product”

“Accepting the work product” is a respectable expectation for a Product Owner. It sounds off and scary but I should add it to my Product Owner role summary.

In a worldview rooted and drenched in hand-overs, separation and blame, anything related to ‘acceptance’ triggers negative sentiments. It brings back memories of rejection. We recall the resentment we felt every time we were blamed for the past and for past actions taken without any room left or given to remediate.

In the iterative-incremental continuum however there is only one way, and that is FORWARD. GO!

The Product Owner identifies and expresses the hopes and desires for the currently most important work. The Development Team acts on these hopes and desires and creates a Done Increment in no more than 30 days, and often faster. The Product Owner accepts the resultant work product against the ultimate goal to discover what is most important to do next with the key stakeholders present.

In my book “Scrum – A Pocket Guide” it is summarized as follows:

The collaborative Sprint Review provides the Product Owner with the best possible information on which to decide whether the Product will be shipped, and how additional Sprints can further improve the value of the product taking into account a balance of risk, effort, budget and cohesion. (p. 53, chapter 2.5.2 “Time”)

There is no absolute guarantee that reception of the presented work product makes a happy Product Owner. However, a Product Owner not being happy with the work product is not the same as the Product Owner rejecting the work product. There is no rejection. There is but one way, forward. Go!

Looking forward the Product Owner might:

  • Not release the Increment
  • Update Product Backlog to better reflect his/her intents
  • Have the work re-done via an updated Product Backlog
  • Decide to increase her/his participation in the creation process
  • Look to increase business skills in the Development Team

I sure hope the Product Owner keeps in mind a close collaboration with the Development Team, as summarized in my book “Scrum – A Pocket Guide“:

Although a Product Owner may have various strategic product management tasks outside of the Scrum Team, it is important that the Product Owner actively engages with the other players of the team regularly and repeatedly. (p. 48, chapter 2.5.1 “Players and accountabilities”)

And, eventually, a Product Owner might not fund a next Sprint or release.

2 thoughts on ““Accepting the work product”

  1. The sprint review becomes a point in which we review end-user’s feedback, review analytics of product’s usage, review the product’s impact / growth, etc.

  2. The sprint review is the first place to gather feedback of product owner and stakeholders. In today’s world we aim to release software on a very frequent basis, thinking about a “continuous” release process. When a feature is ‘done’, we release it (and don’t wait for the sprint review). Sometimes I hear team members asking about whether ‘user acceptance’ is required or not. In my view, when you have a product owner with the possibility of frequently reviewing the work (or trusting the team to create the best-fit solution for the need), we don’t wait for the product owners’ approval. The sprint review becomes a point in which we review

Leave a Reply