Some time ago a colleague of mine, Monica Hervén, asked me for some advice. I was a bit surprised, because she’s a lot more experienced than I am and she’s someone who I have a lot to learn from. The issue she wanted to discuss was how to identify the requirements in a scrum project she’s involved in.
A scrum project starts with an almighty, all knowing product owner that has the entire list requirements prepared in a prioritized product backlog.
The problem Monica faced was that there was no clearly defined, prioritized product backlog produced by the appointed product owner. I don’t think that I had very much new to tell Monica that she didn’t already know, but we could share some experience of the challenges of getting a good product backlog produced.
The product backlog is the initiator for all work done in a scrum project. It’s the responsibility of the product owner to produce it. That makes the product owner role extremely demanding. It is impossible for a product owner to just conjure up a product backlog. Forming the backlog requires hard, structured work to ensure that all relevant user stories are identified.
Features are unimplemented by default; C# does not have that feature because no one designed, implemented and shipped the feature to customers.
Being a developer of custom business applications, I’d like to expand on Eric’s answer a bit.
Features are unimplemented by default; the system does not have that feature because no one listed it as a requirement, prioritized it, payed for it, tested it and deployed it.
What it all boils down to is that there is a lot of work and communication required to ship a feature and nothing is done without effort. To get good results, both the customer and the developers have to take responsibility for their part of the effort.