Three Amigos Teach Us a Lot About Writing Better Agile User Stories

Do You Know the Three Amigos?

Don’t worry. This doesn’t mean we have to write our stories in Spanish! Instead, we’ll explore one of the agile ways of working, the Three Amigos.

We’ll discover what the Three Amigos is with an example of how a session can help a team better understand requirements.

What Are the Three Amigos?

The “three amigos,” translated to “three friends” in English, is an agile way of working where three individuals with different perspectives come together to refine user stories.

These three perspectives, as described by , consist of:

• Business — What problem are we trying to solve?
• Development — How might we build a solution to solve that problem?
• Testing — What about this? What could happen?

Therefore, when refining a user story, a developer, tester, and business analyst (BA) should be present to understand the requirements sufficiently.

How Do the Three Amigos Work?

Let’s go through an example of a team discussing a user story in a three amigos session.

The team sits down together with the following user story to refine:

As an employee, I want to submit my timesheet so I can get paid

Developer: So, what do we need to capture on the timesheet?

BA: We need to capture the number of hours worked each day in a calendar month.

Developer: No problem at all. We can create a form where users can enter their work hours daily. Then, when the user hits submit, can we send an email to HR to process the timesheet.

BA: Unfortunately, an email isn’t going to cut it. We need to send this information to our HR system as we have an automated process for payroll.

Developer: OK, in that case, we can send it to the HR system via the HR API.

Tester: What happens if they enter incorrect information?

Developer: We can provide feedback to the user. For example, we can show a validation message when a user provides invalid data.

Tester: What is invalid data? Can a user enter a negative number for hours worked? Is there a maximum number of hours a user can work on a given day?

BA: No, a user should only be able to enter positive numbers up to twelve.

Tester: OK, we should write a test case to cover this.

Developer: I’ll also ensure we have the appropriate validation for the number of hours.

BA: Also, I just remembered we need to send an email notification to the line manager for approval.

Developer: So, we need to make sure we submit the timesheet in a “review” state, so the employee doesn’t get paid until their line manager approves it?

BA: Correct.

Tester: What if the line manager is absent?

BA: That’s a good question. We should also email line manager B.

Tester: What if the line manager wants to reject the submitted timesheet?

Developer: This is turning out to be a lot of development work. May I suggest we create new user stories for these additional scenarios?

The team agrees the user story is now quite large, so they split out the email notification work into separate user stories for later refinement:

As a line manager, I want to get notified if one of my staff submits a timesheet so I can review it

As a line manager, I want to be able to approve my staff timesheets so I can ensure my staff get paid

As a line manager, I want to be able to reject a timesheet so I can ensure my staff aren't paid incorrectly

Developer: Is there anything else we need to consider for capturing the timesheet details?

BA: I think that’s everything covered. We can iterate on this in the future if we need to.

The team moves on to the next story.

What Did the Team Discover From This Session?

For this single user story, the team discovered the following:

1. Firstly, the number of hours worked for each day of the month must be captured.
2. Second, the number of hours worked must be positive, up to twelve.
3. Third, the form must be validated and feedback provided to the user.
4. Finally, when the user submits their timesheet, the system must send the data to the HR API in a state of review.

On top of that, the team has created three new user stories.

They are now better prepared to estimate and take on this work.

Best Practices

There’s no right or wrong way to refine user stories using three amigos. Instead, I’d suggest trying it out to find what works best for your team. However, here are a few good practices that can help:

1. Timebox sessions — Timeboxing helps focus the team; you can always return to a story later if you don’t finish refining it. 45 minutes to an hour is generally a good rule of thumb.
2. Rotate team members each session — this helps share knowledge amongst the team.
3. Have one member from each area — different perspectives provide additional value.
4. Don’t rush — it takes as long as it takes. Refining stories upfront means we’re not asking as many questions when we’re in development.

Takeaways

From the example above, we can see the value of the Three Amigos.

The developer helped to define the solution to the problem.

The tester provided value by highlighting potential issues.

The BA provided information right there and then, so the team didn’t have to go away to find the answers they desperately needed.

The team is now more confident in taking on the story in their next sprint!

First published