Item

I define an item as anything perceivable or conceivable. For example, I treat a feature, a bug, a task, an epic, or a user story as an item. In addition, I use synonyms such as entity or object. Moreover, I keep the term broad. Consequently, the term fits many contexts in Requirements Engineering.

First, I prioritize items in a backlog. For instance, I use MoSCoW or a high/medium/low scale. Alternatively, I assign numbers from 1 to 100. Thus, I express fine-grained business value. For example, I may give priority 87 to one item and 38 to another. Therefore, I indicate how much more important one item is than another.

Next, I sort items visually. I put more important items to the left. Conversely, I place less important items to the right. Meanwhile, I cluster items on the right side. As a result, I avoid deciding exact positions for low-priority items. Furthermore, I focus on linearizing only the leftmost items. In addition, developers will pick those for the next iteration.

Also, I increase detail for items with higher priority. Specifically, I bring high-value items to the Definition of Ready. Therefore, I describe them more precisely. Consequently, teams can implement them in a near-term iteration. Likewise, I include acceptance criteria or test cases on the card or in linked artifacts. Thus, I create a clear agreement about what the team must deliver.

I follow INVEST to judge item quality. I ensure items are Independent. Moreover, I keep them Negotiable. In addition, I make them Valuable. Then, I estimate them. Next, I keep them Small enough to fit into an iteration. Finally, I make them Testable. If an item remains too large, I split it. For example, I break epics into smaller stories. Subsequently, I refine the pieces so that developers can deliver them within one iteration.

When I face risky items, I choose between mitigation and reduction. Therefore, I avoid the risky option that excludes an item. Likewise, I reject hoping the risk never becomes a problem. Instead, I mitigate risks by allocating time or money. Alternatively, I reduce risk by decomposing the item. For example, I create spikes, prototypes, or UI mockups. Thus, I learn early. Consequently, I lower uncertainty before full implementation.

Furthermore, I supplement simple backlog cards with other artifacts when needed. For instance, I attach detailed acceptance tests, models, or designs. Therefore, I prevent unnecessary work. Likewise, I avoid over-specifying low-priority items. In addition, I update item details as I learn more.

Finally, I treat items as the core units of requirements work. Accordingly, I keep them clear and actionable. In short, I define, prioritize, decompose, estimate, and test items. Thus, I help teams deliver the right product, sooner.