User Stories are the way a non-technical product owner can communicate with the technical team. It is probably the best way any product owner can tell the technicians what he or she actually wants. A the same time it is the best point to pick up technical requirements, limitations and pitfalls related to your requirements. Therefore, take this opportunity and listen carefully. The feedback loop is not only top down, it’s bottom up as well, you just have to use it.

A difference maybe not realized yet

The difference in Scrum related to many other development processes is the rapid feedback you might get during backlog grooming or estimation meetings. Developers will moan about the stories, complain about requirements and tell you more often than not, these particular wishes might be very expensive or even not possible to achieve at all…

Take Action

Even this might be exaggerated, listen because here you get feedback from the folks knowing the software best. Change requirements on the stories, modify the scope, prioritize impossible features down. Nobody else does understand the overall system that well. Non of your architects, managers or analysts understand the system that way.

No means Maybe Later

No does not mean no by definition. If you come up with a story, developers think its impossible, it’s actually not. Stop fighting for the story. Take it, go back to the drawing board and refine or start over. No simply means it too expensive. Always remember: We are talking about technology here. probably everything is possible. It is simply a questions about how much effort one (in this case the product owner) is willing to put into it. If developers say no, they come up with a natural instinct which tells them it simply not feasible under the current circumstances. Always remember, SCRUM is about performing on the very best level under a certain set of circumstances and limitations at a very specific point in time.

Resume

As a product owner make use of estimation meetings and/or backlog groomings. Go over stories again an again and pick up the feedback from your developers. With every meeting you will get better feedback more details and better estimations. Take this opportunity receiving rapid feedback from the developers. There is easier way to get this feedback, though.