User stories and subject hierarchicy
User Stories start with people because good sentence structure has syntactic trees that put the subject first
User Stories start with people because good sentence structure has syntactic trees that put the subject first
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.
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 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.