Customer Versus End User: Does It Matter When Implementing Scrum In Your Organization?

I’ve been spending a lot of time with my clients around the world lately helping to define their customers versus end users.

It matters.

Why?

Well. Most of the time it’s actually defining one or the other first.

Let’s unpack that today.

Customer Versus End User: Why is this this important?

One of the main reasons agile and scrum projects “fail” is because Scrum Teams fail to deliver working products to their end users at the end of each Sprint.

You might think people paying for the project (think “Chickens” or possibly “Customers” as Stakeholders) may be paying for you to deliver the project on-time, within budget, and containing every request as defined in the original project requirements document.

Uh.

That’s fixed-time, fixed-budget, and fixed-scope.

And.

Good luck with that.

What’s the alternative when Implementing Scrum in the real world?

Fix the Time and Budget

If you are Implementing Scrum on your agile project, consider fixing the time and budget.

This really is a simple calculation.

Your time can be fixed to an iteration or Sprint length. Two weeks. One month. Pick one. Keep it short. This is your cycle time (and wow… think about how easy it is to calculate!).

Your budget can be fixed to the “burn rate” of the Scrum Team. If the people are all dedicated to one Scrum Team (another topic for a future blog post lol) then you can take their “fully loaded cost” and make that calculation.

Keep those two concepts simple.

Really.

Focus. #deliver

Now here is your key to success on an agile or scrum project.

Focus on delivering the highest value increments by the end of your Sprint, so you can deliver working product to your end users at each Sprint Review.

Remember — is this regarding your customer versus end user?

Change the Conversation….

A Sprint Review is not a demo, a powerpoint presentation, or an update to your stakeholders on the number of completed Jira tickets / showing a pretty burn-down chart / wowing people with your incredible “velocity” / showing your Gantt charts [yawn].

Eeek.

I am betting some people reading this post are experiencing that today during a Sprint Review (hopefully it’s not you but it #MightBeYou — see DarkScrum.com from my colleague Ron Jeffries to enter a rabbit hole of great information).

The advantage of having a working product to show at the Sprint Review is that you can engage your customers (stakeholders) in a real world conversation about what matters to your end users.

Heck. Invite end users — real people — and get feedback from your end users.

Have a conversation.

Really.

Yes.

This can be tough to do.

Be a professional and try delivering a working product to your end users at your next Sprint Review.

Watch what happens.

The conversation changes.

And.

You can use this feedback to possibly update your Product Backlog to help Sprint Planning for your next iteration.

Rinse and repeat.

Happy Customers.

Happy End Users.

What Next?

Don’t worry about being perfect.

Think about the concepts presented above.

There is a lot to consider.

Pick one thing as a team to work on together.
Maybe discuss this at your next Sprint Retrospective.

Because, think about THIS:

Do you know what your competitors are doing instead of “doing demos” that mask as status report updates to stakeholders?

Your successful competitors are delivering value to both their customers and end users by the end of every Sprint.

Contact me (with feedback) or connect with me on LinkedIn to discuss this more together.

One final thing…

Subscribe to my weekly Saturday morning emails about Implementing Scrum in the real world. And get an “every two week” check in from me too.

What could be better?