The area of biggest challenge I’ve faced in software development is requirements. Nothing earth shattering there. It’s hard to state clearly what you want and it’s even harder to pick what is most important. In consumer applications, using mocks of the UI (simple to realistic) is an excellent aid in driving definition of the requirements. But no one wants to pick what’s the most important feature they need implemented. When asked for a prioritization, they will group features into “priorities”.
As Marty Andrews wrote, “At this point, the stories have not been prioritised. They have been classified into groups, where the group is named “Priority One”. Whilst this may be a useful culling technique, do not fool yourself into thinking they are prioritised.”
Agile forces you to enumerate the list of features (stories, in the agile world) in a single list sorted by importance. The team will work down the list until they have used up the time for that cycle.
The benefit to the implementation team is obvious. There is no ambiguities on what is being worked on. Sort the list how ever you want, they’ll start at the top and work down.
So, how is this good for the product team that didn’t want to make the Sofie’s Choice decision? They realize after a release or two that what wasn’t done last month (pick your weeks… most methodologies suggest 4-6 weeks per cycle) will be at the top of the list next month. Also, there’s no stress involved with the we need everything, including the kitchen sink, because it will be 6 months or a year before this product sees the light of day. It’s not true. If you forgot a feature, you can include it next month. If something low on your list actually should bump up much higher, again, adjust it for next time. The pressure’s off and everyone is releasing product.