Many teams find it difficult to create estimates for their work, whether they are doing so in hours or in story points. In this post, I will focus on elements commonly forgotten by teams when estimating User Story effort. While every team operates differently, these reminders can help your team estimate more effectively no matter what Agile estimation framework you are working in.

1. Always follow your Definition of Done: For every story, make sure you are considering all elements of DONE. Items could include Unit Testing, graphic design/layout time, and time managing the source code.

2. Avoid missing steps in your Story, Acceptance Criteria or Tasks: Similar to our Definition of Done, you want to make sure that you have a list of common tasks that are important to completing a story. Commonly teams forget routine tasks like updating existing data, performance testing or the time required to learn a new tool or technique.

3. Don’t forget non-technical issues: Team members go on vacation, get sick, or are taken away due to other internal company needs. While you cannot estimate these circumstances in your User Stories, it is important to adjust velocity slightly to account for these.

4. DevOps, DevOps, DevOps: Lack of automated build and deployment processes: Getting your development operations squared away will allow the team to focus on development and coding tasks, rather than spending time worrying about the build, long manual deployments and brittle configuration management. This may seem outside the scope of estimating, but when anything more that a single command is required to deploy to all environments, time is required for the completion and validation of all stories and your velocity is affected.

5. Don’t estimate with an incomplete team: It is absolutely critical when the team gathers for an estimating meeting that all stakeholders and team members are available. If individuals are not available, assumptions about unclear or questionable User Stories and Acceptance Criteria will result in inaccurate story estimates and without a team member the team could be missing critical information required to make accurate estimates.

Keep your team focused on good estimating practices using these reminders. Your team velocity should continue to stabilize as you estimate more consistently and effectively. Sometimes, teams find that improving their estimating processes can help them identify points of improvement that can lead to even higher productivity.

Connect with me on Twitter @TMichaelRogers and let me know your tips to you keep top of mind during your estimating.

Working with different organizations over the years, soliciting requirements and properly articulating them are critical and one of the primary concerns I hear from project managers, business leaders and developers. In agile, scrum and Kanban, User Stories are the primary communication method of capturing requirements, their business value and criteria for acceptance.

Development team members crave details. In order to do their jobs properly, most feel that a surplus of information is always best, allowing them to understand the “big picture”. Business people are focused on features and when they will be delivered and don’t need as many details. Product Owners are caught in the middle and need to deliver to both parties.

I have developed the ACTION-able definition of a user story to set clear goals for a “good” story, clarify the amount of detail and write a User Story that communicates just enough information for the team and customers to be happy.

I use the acronym A-C-T-I-O-N to create acceptance criteria for a well-written User Story. Using these acceptance criteria for the completion of any user story you write, will improve the quality of your communication, estimation and the overall team understanding of your user stories. If you find that any of these criteria are not satisfied, then the story should be refined or redefined.

Acceptance driven

Concise

Testable

Independent

One action

Natural

Acceptance Driven

Is your story focused on business acceptance criteria? User Stories are a description of functionality, the individual or role that will perform the story and a brief overview of the business value. The details of those actions and outcomes must be quantified under the acceptance criteria. For example, if I were defining the story “As a customer, I would like a shortened checkout process, so that I can complete my order in half the time.” The acceptance criteria should include details such as desired sales lift this more efficient process should take, or how this change could reduce the amount of orders that are never completed. The criteria should provide the team with quantitative details that can be measured and define when the User Story is complete.

Concise

The User Story should be defined in a single well formed sentence. If your statement is a run-on sentence or you are tempted to use multiple statements, consider breaking it down in to smaller User Stories. To continue our e-commerce example, a lengthy story may be: “As a customer, I would like to see an order confirmation after my order is processed. I should be able to print this confirmation so that I can keep a record.” This story is focused on a seemingly single user story of completing and order and printing a record, but it can be made more concise as two individual stories.

“As a customer, I would like to see an order confirmation after my order is processed so that I may review the details.”

“As a customer, I would like to print my order confirmation so that I may keep it for my records.”

By defining them individually, we gain a better understanding of the user’s motives and needs. Common signals that your story statement is too lengthy are multiple sentences and the usage of the word “and”, as well as other conjunctions.

Testable

Acceptance criteria should be testable through empiric, automated means. Automated testing is important to overall system quality and allows the development team to more easily practice Test Driven Development, ensuring “Quality Up Front”.

For example, “Order processing should be faster”, is not a testable acceptance criteria. “Order processing should complete in under 500ms” if precise and testable.

The product owner should be able to verify each item in the acceptance criteria either through both manual testing and access to automated test reports.

Independent

A user story should stand on its own. Meaning that completing it does not depend on another story. A story needs to encompass a single unit of work a user may take, but it does not have to be working beyond itself. Avoid the temptation to let implementation details cloud the dependencies of a story as well. For example, lets take a look at a common system function of Creating, Reading, Updating, and Deleting (CRUD) a record in a database.  For each operation, each requires the creation of the database to store information. While this implementation detail only needs to be done once, each story should assume that this work needs to be done. This becomes extremely important for planning and estimating. When planning releases or iterations of development, we do not want to have to worry about inter-story dependencies that could affect which story comes first.

One Action

Similar to being Concise, take care to focus on a single fluid action a user may perform. A story can be concisely expressed in a single sentence involving a one role, action and business reasoning, but additional actions can creep into the acceptance criteria and during implementation.

For example, lets imagine a user story for sending email: “As a user I would like to send a short message to another user to update them on project details.” The acceptance criteria may include:

1. The user must enter a valid email address
2. The user must enter a message of at least 1 character
3. The user should be able to select an email address from their address book. <=== BINGO

Here is an additional action masquerading as acceptance criteria. Similar types of features, while valuable and user friendly commonly emerge during development as well. Focus on developing functionality in a single linear path. When new ideas and requirements emerge, capture them in a new story on the backlog.

Natural

User Stories should always be defined according to natural user interactions. If you find yourself describing a system to system interaction or the story is not something a user would need to do with the software as a matter of business, you should re-evaluate the story. It may need to be broken down, or could be a solution in search of a problem. Also, beware of implementation details or bugs masquerading as user stories. While these items can certainly be described as a user story, I believe they need to be treated differently.

I hope you find this technique valuable to apply to your own User Story writing and evaluation. Connect with me on Twitter @tmichaelrogers and let me know about your experiences writing user stories and what tools you find useful.

• It is about business
• It is about clear priorities
• It is about listening to customers
• It is about innovation
• It is about being prepared to pivot when necessary
• It is about hiring the right people, giving them the best tools and trusting them to execute
• It is about teamwork
• It is about transparency
• It is about collaboration
• It is about doing more with less