Estimating User Stories for Developers

User stories are the smallest pieces of functionality that are added to a product. Since the developer role is responsible for creating the code for user stories to work, they need to be aware of the user stories and they should be included in the user story planning and estimation process.

What is a User Story?

Before looking at developer influence on user stories, it is important to know what a user story is. In general, a user story is a short description of a function that stakeholders need the software product to do. It is not at all technical, it is purely functional. In practice, user stories represent small but distinct pieces that must be added to the product. Every individual user story consists of an action that can be performed and tested on its own.

A good way to understand what user stories are is to compare them to tasks. Where tasks are individual pieces of work that must be done, the user story refers to the feature that results from this work. Each task is assigned to only one team member, but user stories may require several team members across multiple roles. Any user story may require multiple tasks to be completed. Tasks come from the Scrum team’s perspective, while user stories come from the perspective of the stakeholders.

The User Story Process

In Agile, there are steps that a user story must go through before it becomes a part of the product. Each of these steps has a distinct goal. While the developer role may not be the driving force, it does help to have developers present in the process. This process starts with the inputs into the user stories, then the approval and prioritization of the user stories, the user story estimation, and finally the commitment to develop the user stories.

Input

The first step of user story creation is input. This consists of getting information from stakeholders on what they want in a software product. There are numerous different methods to obtain input, and methods of obtaining this information vary across different organizations. Some teams prefer for the product owner to meet with the stakeholders, in order to observe the stakeholders workflow. Other teams may issue surveys, to ask specific questions of stakeholders.

Developers are less important during the input phase, but can still offer value in this part of the process. Since the input is still very early in the process, not everything that stakeholders ask for will be included in the product. As such, developers should not jump right into planning and research, since they may be wasting time on features that are omitted. Instead, developers can offer more technical ways to acquire input. From digital surveys to automatic response sorting, developers are typically more tech-savvy than other roles on a Scrum team. This equips them to contribute to the type of input that the team pursues.  The gathered input can then be in a more desirable format for the development team.

Approval and Prioritisation

After the stakeholders have given input, the Scrum team begins to put together user stories for approval. This includes a number of different steps to create the most useful and direct user stories. The Scrum team must examine whether something counts as a full user story or just a trivial action. Many small actions might need to be combined to be a single user story. On the other hand, large stories in the form of epics may need to be broken down into several smaller user stories to cover individual features.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum:

Master of Agile – Agile Scrum Developer With 59 Seconds Agile (Video Training Course)

Introductory Offer: Free Course