When delivering customer value, we lose focus.

Delivering customer value should always be in the focus. The Product Backlog and the written User Stories should reflect value and set the direction for the product. However, this proximity to the customer is difficult for many companies to achieve, especially in large organizations.

Expectation vs. reality

You get the desired Santa Claus at Christmas, open it and see the rabbit. I also like the Easter Bunny, but it’s about the customer having an expectation and this is clearly not being fulfilled.

Challenges and emerging mistakes

Individuals and teams face challenges. In an agile product organization, management should work with the product organization to promote an agile culture. The challenges result in mistakes. This can be due to the missing empowerment from the top, how the teams are split, the composition of the team or individuals within the team or the lack of access to real users.

Challenges:

  • We want to deliver customer value, but we are not sure what the user actually wants
  • We want to make it right for all stakeholders and take everything + can do everything
  • Management increases pressure and sets release targets for the team
  • There is no real agile product organization that supports us
  • We have dependencies to other teams
  • It is hard for us to become across-functional team

We make mistakes and maybe even look away sometimes:

  • We do not provide end-to-end features and need multiple sprints to release complete features
  • User stories are not written from the customer’s point of view
  • Some requirements are not testable and therefore reveal a high degree of risk or misunderstanding
  • Items are too big and therefore require multiple sprints
  • The team splits the requirements in components and horizontally rather than vertically
  • Everyone is focused on their expertise = functional silos

INVEST Principle

If you now take the mistakes that arise from the challenges, compare it against a user story with the INVEST principle you will be able to observe that violations are inevitable

  • Independent – implementation without order
  • Negotiable – No contract. Collaboration between customer and team. The goal is the delivery of customer value
  • Valuable – Must be customer centric and useful to the customer. The backlog indicates a priorization.
  • Estimable – Has been understood so far that it can be estimated.
  • Small – If too big, then there is an increased risk
  • Testable – the testability of a story is reflected in the acceptance criteria. When is a story really “done”?

A practical example:

“Do we want to split the item in frontend and backend”. All developers nod enthusiastically. “Great, then one team takes care of the Frontend and the other does the backend”.

Violation against Independent = The item is cut into components.

Violation against Valuable = The item does not provide a customer value.

Violation against Negotiation = There is no proper collaboration between user and team. If the item is divided into FE and BE no customer value is created. The user is not involved in the collaboration because of the technical details.

So why are we looking away?

There are a variety of reasons. Reasons could be the lack of support from the management, individual goals in the matrix organization, too few opportunities for further education and progression in your job and perhaps also missing time.

Management Support

The management does not provide support. The result is frustrated product owners and teams, which have arranged themselves with the situation. “Let’s just release that thing somehow, it’ll work out eventually”.

Goals in the matrix organization

There are individual goals in a matrix organization that do not really help us. Goals that the department has, the department head and they are also pushed on the employees within the department. These goals can sometimes be contradictive to the product organization and give the Product Owner + Team no chance to deliver real value. I worked with a team this year. The PO is not just responsible for one team, but for several. At some point, his commitment to the team was down to 20%. His supervisor advised him to do so. This does not allow him to perform his Product Owner role in any way. The 20% are just enough to participate in the Sprint events and maybe readjust here and there. But that’s it.

Further education and career opportunities

The word progression implies that you see a path ahead of you. If this path is blocked by structural obstacles in the company, the motivation of the employee is also lost. Jim Harter explains this well in his article on bad employee engagement as a sign of global mismanagement. Based on the gallup report, 85% of employees are not engaged or actively disengaged at work. This may also be due to a lack of training opportunities.

Missing time

Actually the biggest problem of product owners in a product organization. They are the real constraint of the team most of the time. As mentioned briefly above, purely by definition, the Scrum Team should dedicate 100% of its time to the product. For example, if the PO is dragged back and forth, from one team to another and then regularily rotates between them that will just not cut it. No way you can do a proper job as a PO. At some point you will look away, because you have to or just do not want to end up with a burnout.

How to write better agile user stories

User Stories Masterclass

In my most recent online course I am addressing common challenges and mistakes when trying to deliver customer value by writing user stories. This course focuses on introducing effective methods to write better user stories and build more successful products.

COUPON CODE: USM50


Leave a Reply

Your email address will not be published. Required fields are marked *