Delivering Value by Identifying Pain
I learned a valuable lesson from a co-worker today as feedback from a sprint review he attended that I was leading. He said “It sounded like I was hearing pain from the users.” He was exactly right and I was not listening to it. It was a great way to put one of the fundamentals of software delivery, always be adding value for your users.
Looking back on the sprint review and at some of the solutions we delivered, they were technically awesome. The realization from a person outside of our product team that we were hearing pains led me to belive that while we may be delivering great technical feats, we may not be solving the correct problems of the users and the business. This pain the other product owner was hearing should have been identified before the sprint and addressed directly instead of discovering it after a sprints worth of work and having the problem bubble up.
Because of my knowledge of programming I find myself bringing technology into the problem discovery (Pain Identification) phase and that is WAY to early in the process. This phase is for listening and understanding and not for solving the problem. I find the difference in the way product owners lead their teams very interesting given whether they come from a programming or business background.
I am learning the hard way the reason user stories are important to delivering value and “Identifying Pain” as they should be written in such a manner to solve a problem an actual user is facing. If the stories are written correctly and programmers are delivering solutions based on those stories there is little doubt the users pains are being alleviated.