Something that’s commonly used by Scrum teams are User Stories. They’re used as a way to keep development concentrated on solving an issue rather than developing a feature. Often times they result in the same things. For example, a user may want an extra setting in a script for automatically making links in an article open in a new tab (target=”_blank”).
The setting might allow them to exclude URLs by domain. There are two ways this might be done. In many workflows, the person responsible for making sure this feature gets done would tell a team member to “implement a setting feature for excluding URLs by domain”. There’s also a fair chance he’ll tell the team member where exactly the field should go, and any other aesthetic features.
The team member will get it done, mark it off the list (send send it off for testing), and continue onto the next feature. For Scrum teams, though, there isn’t a specific person in charge of assigning features to specific people. Not only that, but the process of planning out a specific feature, getting it done, and handing it off is contrary to the Agile principle. Enter user stories.
A user story is written in the following format:“As an X user I want to be able to accomplish Y.”The reason for using that format over slapping a feature onto the to do list is it both gives you a bigger picture of why you’re creating a certain thing, and ensures that what you’re doing will stay in line with the reason you’re doing it. Part of the process of using user stories is to ensure that when the feature is complete, that it still meets the goals of the user story. This also allows for a clear definition of when something is done – if the user story can be completed by using the new feature, the new feature is complete.
Another great plus is that as the developer creating the feature you can now test it yourself, by acting as the user in the user story.