Writing a User Story | Requirements | Business Analysts [SteveMiami]

The Business Analyst (BA) is the bridge between the business world and technology. The BA collaborates with Stakeholders to understand business needs and define, translate and prioritize them in User Stories as features for software engineers–with a goal of delivering solutions that have business value

A user story represents what the team can deliver in an iteration. Ideally one user story can address the entire business value, but in reality the user story represents a portion of the greater goal.

Is your product owner the right fit for the role? Placing the right person in the product owner role is crucial for a successful product.

☢ Tell stories from the user’s perspective -- don't fall into the abyss and start writing technical tasks.

☢ Use Personas.  Make a chart with names and pictures of the persona; and include characteristics and behaviors such as common tasks, job responsibilities and demographics. Include the goal for this personal and problems the product solve for this persona.

☢ Avoid roles like 'user' and ‘developer’ when writing stories.  Create explicit roles such as "Senior Editor", "Web Visitor" and "Product Owner".  When writing stories “As a Developer…” take a step back and write from the product owner’s point of view.  Often ‘as a developer’ stories are tasks of another story.

☢ Don't work in a vacuum, with blinders on. Communicate and collaborate! Product owners and the team should discuss the stories, or imagine this, write stories together.

☢ WTF. Avoid confusing and ambiguous terms in stories.  The product owner, as well as developers and quality assurance testers, should be able to read and understand the story.

☢ Writing and Styling. If one story writing style isn't working out try different ways to write your stories to understand what works best for you and your team. The retrospective is a great way to communicate the concerns over writing styles.

☢ That's epic! Epics help define new products and new features: It allows you to capture the rough scope of the project.

☢ Stories should be coded and tested in a single iteration--ideally in a few days.  Epics should be broken down, but not so small that a story becomes a detailed design spec.

☢ Capture critical details about the story as acceptance criteria. The product owner should list as many acceptance criteria as possible in order to clarify the intent of the story.

☢ Remember the customer's needs. If you skip the acceptance criteria conversation, you may be missing the edge cases or forgetting about the customer needs.

☢ Communicate! This means within your team and with the client. 

Steve is a Digital Product Manager based in New York City. Most recently implementing Content Management Systems with customized features for entertainment publishing. He known for solving problems, optimizing product features and creating happy users. Steve is actively interviewing and would like to join an Agile team as a Business Analyst / Product Manager. You can learn more about Steve's skill set and background at http://linkedin.com/in/steveapple​

Source: SteveMiami http://bit.ly/2piMCvS