Gain Your Clients Trust By Writing Productive User Stories

Submitted by Jill on Sun, 09/21/2014 - 13:54
User Stories

The foundation to any sprint and feature development is the collaboration between what the client needs and what the developing team implements. The foundation of understanding the need, request and implementation is laid out in what is called a user story. A user story should encompass a story type, estimation of effort, story format, comments to track collaboration and a workflow state to understand what process the story is in. User stories should be just that, a story told from the perspective of a user that describes the business value. In addition, the story should encourage collaboration and provide transparency in progress. If you are interested in improving productivity of your clients request this article will provide solutions.


If a user story documents request the sprint defines the journey a user story takes. Every request is converted to a user story with a beginning and end. The Sprint is the vessel used to wrap several user stories for delivery. Sprints provide everyone involved with expectations for what happens to a request and how it is delivered. All parties involved in development including the client, product owner, project manager and development team need to understand the length of a sprint and components of a sprint. This article is not intended to articulate how to manage sprints, but an agreement on the basic components of a sprint is required when discussing user stories. For this article lets agree the basic components of a sprint are sprint planning, story estimation, daily stand ups, release for demo and demo with product owner approval.

Story Types

Request should be categorized to understand their priority. You have a typical feature request that requires a user story to implement a new feature. You may have a bug request that correct a fault created during development of new features, and you may have a support request that is not part of the current work. It is important to identify if this request is a typical feature request following the normal sprint workflow, a bug request that is part of the agreed work and needs higher prioritization, or a support request that is not part of this agreed work, will affect the deliverability of the agreed work, but still needs addressing. Having a story type as part of your story helps organize and manage expectations.

User Story Components and Structure

Each user story has components used to define, analyze, track, perform quality control, document steps for release, monitor the state of the story, and track conversation. All components are needed to productively collaboration and deliver on the clients request.


Structure for a request is first defined in the title. Each title should follow a specific structure to provide clarification on who the request is for, the pain point needing to be resolved and the business value it provides.

Traditional user story structure:

As a <type of user>, I want <to perform some task> so that I can <achieve some goal>.

At Zilleem we like to use a template focused on being a catalyst for business:

As a <type of user>, I want to <improve some pain point> so that I can <add business value>.

Encouraging conversation is key to the user story and the story template not only defines the story, but also encourages collaboration and conversation. A request usually start very simple like, “can we add a link to products”. This request may come from the product owner, or someone else in the clients organization. Using the template above we first need to a have a conversation before we can create a story.

Type of user: Our first question is what type of user is the link for? Is this link for the administrator, or a customer? This information will immediately let the development team understand any access permissions and layouts involved.

Pain Points: We then ask what pain point need to be resolve. Will this request solve the pain point, or should we propose additional solutions. In our example the pain point is that customers are not finding products. We may want to add links to a menu, provide a landing page layout linking to popular products and provide a more products link. We may also explore other options with the client dealing with SEO (search engine optimization) and marketing.

Business Value: When the conversation turns to business value we learn the client has new products they need to highlight. We may propose a new category for their products and/or a new section on a landing page.

The results of a request to “add a link to products” results in a conversation that defines a user story.

As a customer, I want to discover new products from the home page so that I can easily order the latest version.


During Analysis the development team will identify what is needed to resolve the pain point and bring business value. From our example above our team’s analysis may come up with creating a new category for products, developing a new teaser layout for the home page, linking the products in the new teaser and adding a view all link to the teaser. Depending on the complexity the analysis may define steps to achieve the results, or (when couple with the estimate) require this request to be broken into several user stories.


The quality control component should provide steps for reviewing the user story and validating the request as complete. The documented steps should be written in a way that allows a user without much knowledge of the product to complete the steps. Ideally the product owner will approve of this section before development begins; providing confirmation and agreement on how to verify what completes a user story. An example of a well documented QA component…

  1. As a customer navigate to the home page.
  2. Scan the home page and identify new products.
  3. Choose a new product to view and confirm you can click on the product to view.
  4. On the product page add the product to your cart.
  5. Navigate back to the home page.
  6. Scan the home page to identify new products.
  7. Choose the view all new products.
  8. Choose a product to add to your cart.

A successfully QA component has approval from the client/product owner before development begins, includes clear steps to perform quality control and could be used during a demo to confirm approval of the story.

Release Steps

When developing software release steps are important to document what steps are needed to reliably deploy changes to environments. Project should typically have a development, staging, and production environment. Some project have additional environments, but the basic setup should include method to bring together development, test and stage for demo and release approved features to production. Release steps will look different depending on the story, software framework and deployment process. Steps may be manual, code integration like branch mergers, code updates for schema updates and additional steps needed to apply code changes during deployment. A good deployment process will have automate schema and code changes reducing the steps needed for documentation, but documenting the basics release components and steps helps isolate issues, if/when they happen.


Every story requires estimating. Two basic types of estimating is to estimate by hours vs points. Estimating by hours is usually preferred by those monitoring the budget while developers usually prefer estimating by points. Zilleem prefers estimating users stories using the Fibonaccie point system of 0,1,2,3,5,8.

Fibonaccie point system starts with 0 as no effort and goes up to 8 with the most effort.

Using a point system does not mean the project is not accountable for hours and should still be monitored by the project manager, but allows team members to estimate stories based on effort. Each story is estimated on effort and preferably estimated as a team during sprint planning. Once the members of a team agree on the effort required on a story the appropriate Fibonaccie number should be assigned on the story. Sprints should have a maximum amount of points allowed and as many stories that can fit into a sprint create the deliverables for that sprint. If all stories are completed in a sprint team members will pull additional stories from the backlog. The process of having a maximum about of points to start the sprint, but allowing more stories to pull from the backlog provides a better understanding of what a team can produce when evaluating multiple sprints. It is also important to remember each member of a team will have a different level of effort depending on their experience with the development needed for that story.

User Story States

Every story has a beginning and end, or a start and accepted. Between the start and end are additional states showing what process the story is in. Basic states of a user story should be start, blocked, finished, delivered and accepted.



  • Started (Developer starts work)
  • Blocked (Development can not continue because...)
  • Finished (Development complete )
  • Delivered (Integrated on staging for QA)
  • Accepted (QA steps performed and approved)

When a team member starts work on a story they should change the status of that story. Each day during standup the status will show and reflect what the team member is working on. If the story is blocked the status should indicate blocked and steps should immediately be taken to resolve the issue. Once development is complete the status will change to complete and be available for delivery. Integration is then performed using steps documented under release. Once the user story is available for QA (some project may perform this on staging, or on a separate QA environment) QA steps are performed and the product owner accepts the user story.


Writing productive user stories creates conversation and collaboration removing pain points and providing business value. Performing analysis helps understand the steps needed to complete the story and leads to a deeper understanding for estimating the level of effort. Documenting quality control steps for confirmation and release steps for deployment create accurate and reliable releases. When clients understand the value proper structured user stories provide, understand the deliverable timeline and state for each story, appreciate the predictability and reliable of confirmation and delivered releases you will gain a respect from your client and grow your partnership by providing a business value.