How to describe the business entities in Scrum?

Question

Every (software) project comes with business entities: "Article" and "Category" for a blog, "Product", "Customer" and "Invoice" for a shop, etc.

These business entities are part of many user-stories : one to describe the creation/update form, one for the detail screen, one for the back-office screen, and much more.

In a non-agile project, you describe all these entities in the specifications, but in Scrum there is no such thing.

So, how do you write all these users-stories ? Do you repeat all the properties and relations each time?

Examples:

• As an admin, I can add an "Article" with a title, a content, one or more Category.
• As a user, I can see the title, content and the Categories of an Article
• ...

What do you think?

Answer 1

There is nothing in Scrum that's keeping you from defining your business entities somewhere and then referencing them in the stories.

The agile approach only means you should be able to change those definitions if necessary.

You will still need to add details to your user stories, "display an article" is way to broad and open for interpretation, even if the whole "article" is specified somewhere. You probably want a different display for a shopper and an admin for example.

Answer 2

A user story is an invitation to a discussion. It is not intended to be a detailed specification.

All the user story needs to communicate is the basics of a requirement and it is worded in such a way that it is understandable by the person who will derive value from it.

As an admin, I can add an "Article" with a title, a content, one or more Category.

This is not a user story. It is just a requirement written using some of the user story format.

A user story would be something like:

As a user I want to see the title of an article so that I can quickly tell if it is of interest to me

A user story does not need to contain enough information to allow a development team to build the feature. Instead, the user story is the starting point of a conversation between the Product Owner and the development team. During that conversation details will be added which might include discussion of entities and their relations.

The user story is deliberately made light on detail. This is done for several reasons:

• The more detailed the description of the requirement, the shorter the shelf-life will tend to be.
• Simple stories are usually easy to prioritise.
• We do not invest too much time adding a detailed description to a story because it is not needed until we are close to the point of implementing it. This just-in-time approach makes us better able to deal with changing requirements.

Answer 3

As others have said, the Scrum guide doesn't define business entities, but it does speak to them in principle.

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

One body of techniques by which a PO does this falls generically under product management. Two product management outcomes the PO is responsible for seem to inform use of business entities:

• Clearly expressing Product Backlog items;
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

My guess is that discovering, defining and using business entities is a way of communicating domain knowledge. If so, I'd recommend domain driven design and the book of the same name as a technique to consider as a complementary practice to Scrum. You might define these entities in wiki pages, shared docs, even the code base e.g. class, module, variable names as a way of establishing a domain specific language to enhance user empathy and efficient communication. It does seem likely to me that these entities could well be used in Product Backlog items like user stories.

Answer 4

TL;DR

You're conflating a lot of things, and trying to convert the user story format into a new type of specification. It isn't one.

Instead, you should modify your process so that everyone shares a common knowledge base, and then break down user stories during Spring Planning into implementation tasks on the Sprint Backlog. You should also increase collaboration with stakeholders within the Sprint, and ensure that you hold framework ceremonies such as the Sprint Review to inspect the increment of work.

The power of agile practices is in leveraging an incremental inspect-and-adapt cycle, rather than in extensive upfront planning. Agility requires iterative processes, and your current way of defining work is not truly incremental or iterable.

Glossaries, User Stories, and Sprint Reviews

Define a Glossary

Even terms like "entities" are a ambiguous outside your particular business domain. On most agile projects, I've found it's extremely helpful to create a glossary as a project artifact, and then keep it updated with terms that we define within our organization or process. For example, you might have a couple of glossary items like:

• Category

  A tag for a blog entry that can be used by administrators to organize content, or by users to find similar articles.

• Article

  A blog entry whose Definition of Done includes having a:

  1. Title
  2. Category
  3. Content

This glossary must be kept updated, and is used as the canonical reference for terms in your user stories and tasks. You might even use markup (e.g. italics, quotes, underlining, or colors) to identify glossary terms in your backlog items, although I've rarely found this necessary in practice.

Use the Full User Story Format

When properly done, a user story contains:

1. A value consumer.
2. A value increment.
3. A context to constrain or scope the increment.

Your current stories don't do those things, and so you lack sufficient information to understand the story's narrative or break it down into implementation tasks. For example:

As an article contributor,
I want to have a single-page interface for adding an article
so I can add a title, content, and one or more categories all at the same time.

This story provides a role with a point of view (the value consumer), what that person wants (leaving the implementation details to the development team), and some context that helps the development team understand the value proposition and acceptance criteria.

This type of story is much easier to break down into tasks for the Sprint Backlog. It also serves as a great focal point for conversations with the stakeholders throughout the Sprint as the team develops acceptance tests and fleshes out implementation details. A user story is a means of collaborating, not a way of tossing specifications over the wall!

Leverage Your Sprint Reviews

Scrum is all about inspect-and-adapt. Even in cases where you have low stakeholder engagement or can't actively collaborate throughout the Sprint, a short iteration ensures that if you build the wrong thing—or build the right one, and the stakeholders realize post-facto that it doesn't really serve their needs—then the process ensures that these issues are caught relatively quickly and can be iteratively changed or improved.

This means that even if you don't leverage user stories effectively, every week or two the stakeholders will see a potentially-shippable increment. They don't get to say "You did it wrong!", but they do get the chance to say "Well, I guess what we really wanted was..." and create new work which the Product Owner then prioritizes for a future Sprint.

Scrum (and agile processes in general) are about emergent design, incremental progress, and iterative improvement. So you don't have to deliver something perfect every iteration; you simply have to deliver something "good enough for now," or at least "good enough to solicit meaningful feedback." Either way, the Sprint Review is a useful process control when correctly implemented.