Test Driven Refinement
Agile is a very powerful and effective approach to delivering software whether you’re a startup or larger organization with 10+ development teams. At my last organization we had multiple agile teams that were usually comprised of 2 quality engineers, 4 developers and a dedicated product owner. Each team would regularly refine their backlog, plan for upcoming sprint work and hold retrospectives.
In this article I want to talk about some tweeks that your development teams can implement to reduce rework and increase throughput.
Let’s start with the WHY
Reduced rework
Rework can happen for a lot of reasons and is not 100% avoidable. For example, let’s say you get a lot of unfavorable user feedback on some app functionality. To keep your users happy, you decide to make some changes to work you have already completed. While rework can’t be totally avoided, you should try to mitigate it as much as possible.
In software development, rework usually means: code changes, quality testing, and other processes surround those tasks. These things all take time, so depending on the stage of development it’s discovered, rework can be very expensive.
Increased throughput
A teams velocity is a relative value that’s calculated by the amount of work the team committed to versus how much was actually completed, over time. I.e. how much work can a team budget for and confidently deliver in a given sprint.
Overconfidence is a common mistake I’ve seen in development teams, especially in the early days of establishing their velocity. A former manager of mine would say, “Hope is not a strategy” which I interpreted as “It’s important that teams are confident but also realistic”.
While increasing the teams throughput can certainly lead to a higher velocity over time, I believe it’s more important that the team completes what they commit to. This gives the development team, product owners and internal stakeholders a greater sense of confidence as to when they can deliver value to their clients.
Test driven refinement
Let’s assume that the product team has created some high level features that are then later handed down to the development team for refinement.
A typical feature might look like the following:
Title
F-149 Allow users to see information about a restaurant in augmented reality
Acceptance Criteria
Users should see augmented information when pointing their device at a restaurant.
Functional requirements
f-req-1: A user shall be able to see the restaurants hours in augmented reality.
f-req-2: A user shall be able to see the restaurants menu in augmented reality.
Non-functional requirements
nf-req-1: Augmented objects should appear in under three seconds.
The feature above is usually refined by the team in the following way:
- The team reviews aloud the title, acceptance criteria, functional requirements and non-functional requirements.
- Derive some user stories, define their acceptance criteria and add some tasks to the story.
The biggest contributors of rework and reduced throughput that I’ve observed are:
- Often times the person most familiar with the feature or user story ends up driving the process. The issue here is that others tends to sit back and coast through the rest of the motions.
- Individual team members have their own nuanced interpretation of what we’re going to deliver to the user. Integration tests are written under one assumption a, manual test cases written using a2 and development a3.
- Since the team isn’t on the same page, the right questions for product and other teams such as UX are not asked until later on in the development lifecycle.
So how can we improve in these areas?
Supplement with TDR:
Title
F-149 Allow users to see information about a restaurant in augmented reality
Acceptance Criteria
Users should see augmented information when pointing their device at a restaurant.
Functional requirements
f-req-1: A user shall be able to see the restaurants hours in augmented reality.
f-req-2: A user shall be able to see the restaurants menu in augmented reality.
Non-functional requirements
nf-req-1: Augmented objects should appear in under three seconds.
High-level acceptance tests
Given that the restaurant hours data is available
When pointing the phones camera at a particular restaurant
Then the restaurants hours are shown in AR
Given that the restaurant menu data is available
When pointing the phones camera at a particular restaurant
Then the restaurants menu is shown in AR
Given that a user has the app open
When pointing the phones camera at a particular restaurant
Then the data to present in AR should not take more than 3 seconds to load
Notice the addition of high-level acceptance tests. It might seem like a simple change but in practice it has proven to be a power exercise.
Lets break it down:
- Tests are written in the given, when, then format. This helps us think more from the users perspective.
- Tests should cover the functional and non-functional requirements.
- We don’t want to cover every permutation of tests so keep it more high-level.
These are some of the benefits I have seen first hand from TDR:
- Individuals start to question their assumptions and contribute more to brainstorming. This begins aligning the teams thoughts.
- Additional dependencies are discovered and the team has consensus on what additional clarification is needed from teams like product and UX.
- Missing requirements are found and redundancies are eliminated simplifying the feature.
TDR can also be applied to user stories
Here’s a sample user story derived from the feature about supplemented with TDR:
Title
Display the restaurant menu in AR
Acceptance Criteria
When a user views points their phone at a restaurant it should display the restaurants menu in AR.
High-level acceptance tests (from the feature)
Given that the restaurant menu data is available
When pointing the phones camera at a particular restaurant
Then the restaurants menu is shown in AR
High-level acceptance tests (user story specific)
Given a secure service endpoint
When calling it with the restaurants id
Then a json response containing the restaurants information should be returned
Notice that in addition to defining the user stories own high-level acceptance tests, you also bring in the ones from its parent feature where appropriate.
Summary
TDR is a supplemental exercise designed to help your teams collective thinking which will yield a increase in throughput and reduction in rework.
Please feel free to reach out with any questions, comments and feedback you might have.
