User stories or business requirements
Why write User Stories?
User stories help us to understand what a customer needs to happen in order for them to achieve their objective.
User stories are one of the outputs in the journey of helping customers achieve their outcomes, but they are only an effective toll for this if the other steps of the journey have lead us this way. If we’ve never spoken to a customer to understand their needs, then we cannot write an authentic user story to express those needs.
Often, rather than having user stories that express the value outcome a customer is going to achieve, we have business requirements that describe the functionality the business expects to be delivered.
Writing business requirements instead
Business requirements are different to user stories. They are taken from parts of the business that haven’t spoken to any customers and express what is expected to be delivered in return for the investment of time and/or money.
Writing business requirements isn’t bad. It isn’t any less agile than writing user stories, but it is what it is, and shouldn’t be falsely wrapped up to look like user stories and pretend that they originated from the customer or to convince us that by delivering against those requirements we’ll achieve something for the customer.
Both are about delivering value
Both user stories and business requirements have their place. They both express a value exchange. One is between the customer and the business, and the other is between two parts of the business. If we want to deliver value continuously (which we most definitely should) then we need to be clear who we’re delivering value to.