Slicing by Roles
User stories often involves a number of roles (or groups) that performs parts of that functionality.
Take a user story to publish new articles to a public newspaper website:
As news organization I want to publish new articles on our homepage, so customers have a reason to return periodically
By considering the various roles that are involved, we can break the functionality down into the following bits:
As customer I want to read a new article, so I can be informed of important events;
As journalist I want to write an article, so it can be read by our customers;
As editor I want to review the article before putting it on the site, so that we can prevent typos;
As admin I want to be able to remove articles from the site, so that we can pull offending articles;
As customer I want to review and confirm my order, so I can correct mistakes before I pay;
By breaking up functionality into the roles that have to perform bits of that functionality, we more clearly understand what functionality is needed and can more accurately estimate the work involved. Writing user stories is a great way to apply this strategy. It also helps the product owner prioritize. Some roles may be less relevant at the moment, and can be implemented later. Perhaps there is not yet need for an editor. Or the editor can be called by a journalist to check the article manually.
