Agile Development

Defining Acceptance Criteria Using the “Steel Thread” Concept

 Many times, teams struggle to define clear acceptance criteria. Acceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. However, many times the acceptance criteria ends up being what the story is not supposed to be, or does not include enough information about the functionality expectations of the story, so that the teams don’t know exactly what to test. However, there is a way to simplify the process of defining acceptance criteria called the "Steel Thread" concept.

The term "Steel Thread" refers to the idea that the system’s main functionality is like a "thread" that runs throughout the system. Everything is based on this thread, and it is therefore, very important. Its importance is what makes it strong, like "steel".

The way to use the steel thread approach is to decide as a team just what constitutes the steel thread. This should be the main function or the primary function of the user story that provides some tangible outcome. Then the acceptance test can be focused and targeted to verify that everything within this main function or "steel thread" is working correctly. This does not mean that there is only one acceptance test, but that each acceptance test that is written cannot go outside of the limited scope of its "steel thread".

The following is an example of using the steel thread approach for a user story that reads: "As a user, I can configure widget B to display in one of the three primary colors of blue, red, and yellow."

A set of acceptance tests would be:

1.            User has access to the configuration options for System X

2.            User has a selection list available of the three primary colors of blue, red and yellow

3.            When a user sets System X to blue, it displays in blue

4.            When a user sets System X to red, it displays in red

5.            When the web master sets System X yellow, it displays in yellow

6.            When a user has no other options other than blue, red or yellow

Now, if you need to check and make sure no one else has those abilities, you should write a different user story. This one might be: "As a user, I do not have access to System X configuration options". Then you would write another set of acceptance tests for this steel thread.

By following the steel thread approach, your team can insure that each of the user stories is fully functional, and you can complete one user story in a particular iteration, without any unnecessary bleed over.