Many teams hesitate to increase business value by refining, estimating and ordering Backlog items in proper time, using proper tools, and with the appropriate goal in mind. I don’t want to blame the requirements management based on the User Stories, but lack of an effective toolkit to manage requirements often degrades the team performance. The framework prescribes to order Product Backlog items by their “value.” Still, a typical process of requirement management doesn’t offer a working method to make that abstract value visible and measurable, and so usable for comparing and sorting PBI items. A handy yet simple method widely used in the Unified Process for a similar task is called Five Attributes. These attributes play the same role as value (an indication of how much the customer needs the story) and story points (an indication of how scary the user story looks to the team).

The Product Owner assigns two of the five attributes. These two attributes give us a clear understanding of the business value of a story.

The first attribute is “importance.” “Importance” indicates how much the story will affect the customer business. The estimation ranges from “the business cannot run without this feature,” trough “the business will significantly benefit from this feature,” and all the way to “it would be nice to have this feature, but we can live without it.”

The second attribute is “urgency.” “Urgency” indicates how soon the business needs to have the story done.

Please keep in mind, “urgency” and “importance” not always correlate. It is quite possible to have an optional but urgent functionality, for example, if such a feature is supplemental for a time-limited marketing campaign, so it is needed either right in time or isn’t needed at all.

The Development Team assigns another two of the five attributes.

The third attribute is “complexity.” “Complexity” indicates how well do the development team understands how much work is required to do the job and how to do this job.

The fourth attribute is “volume.” “Volume” indicates how much work is required to have the user story done.

Again, the complexity and volume often do not correlate. It is quite possible to have a large but simple, or a small but complex job to be done.

And finally, the whole Scrum team assigns the last but not least attribute – “clarity.” This attribute indicates how clear the customer itself and the development team understand the goal, the context, and the expected result of the user story.

The numeric value assigned to the attributes does not matter. It may be a 3/5 or even ten number scale, a letter designation, or high/medium/low. Whatever the team is used to would be the best option.

Now let’s discuss how to use these attributes.

Let’s say we conduct a sprint planning meeting and need to select stories for an upcoming sprint. Important OR urgent user stories with low complexity and low volume are the best candidates to produce a releasable increment and maximize the value of the product, as Scrum requires us to do.

“Complex” user stories are good candidates to be considered as a technical spike, and if they are “urgent,” it may be wise to explain to the customer that the dependence on these stories may be risky.

“Large” and “Unclear” user stories are good candidates for a backlog refinement session. The team may want to decompose these stories further to make them “smaller” or may want to include prototyping into their backlog to help stakeholders understand their needs better and explain them by criticizing a prototype, which is always easier for people.

So, using the “five attributes” method makes backlog ordering easier to sort and manipulate for each particular task and increases the transparency of the whole requirement management process.

You may want to add more attributes, but be careful, don’t let attributing be the goal. These attributes are just a tool that should help, not a valuable product, so do not waste your precious time on something that does not improve the product or the process. I am using this method for more than 15 years with constant success. I tried to add more attributes. Still, it appears that you need more attributes only on infrequent occasions, typically when the product is not a typical product to support a business process, e.g., you are developing a compiler for a new programming language. I also tried to reduce the attributes set, but it appears to be impossible to avoid ambiguity and misinterpretation (as you can see widely happening with “value” and “story points”).

P.S.

If you are interested why I decided to share my experience of enriching Scrum with Unified Process practices, please read this blog post

Please do not consider the fact that we may and must augment Scrum with supplemental techniques as proof that Scrum isn’t good enough and must be changed. Quite the opposite, the proper toolkit will help to implement the full Scrum framework and let Scrum shine as it deserves to.

About the Author

My name is Nikolay Gekht, and I am the CTO of Gehtsoft USA, a salted project and product manager with 20+ years of experience in creating products and establishing development processed under Unified Process, Scrum and DevOps.