We'll be developing an app that manages a todo list. Let's develop an MMF for the app. The MMF is an important element of organizing our specification in BDD. First, let's start with the justification of value. The common structure for these justifications is in three parts:

As a …
In order to …
I want to …

The idea is to specify the role of the user first. Then we write what the value is to that user. Finally, we describe how the user achieves that value. The feature itself is only in the last part, but the first two parts provide important context. We can also expand each part to have multiple declarations, simply by using the conjunction and.

Without further delay, let's write a justification for a todo list manager app:

As a user
In order to keep track of what I need to do
And in order to keep track of what I've already finished
I want to add todo items to a list
And I want to mark them as completed

The preceding description seems obvious and not remarkable. We'll work on improving it. But first, let's look again at the structure. The first sentence specifies the role of the person using the feature. We've defined the role as user, which is very generic and doesn't shed much light on who this feature is really aimed at.

The next two lines specify the value. We've given a little bit of detail, but it's somewhat vague and repetitive. We'll have to improve this.

The last two lines specify the two main features of a todo list manager: adding an item and marking it as completed. This is good. We could have added more detail, such as I want to see my list of items, but that is already assumed. In general, we don't want to be exhaustive with every single thing that the feature does. Rather, we want to highlight the important parts.

Let's work on improving the justification by first thinking about the role of the person using the system. We could come up with some ideas about what kind of person would benefit from a todo list manager app. Perhaps someone who is busy, or somebody who likes to be very organized. There aren't any obvious answers here. The point is to clarify for a particular team, organization, or engineer, who the software is intended for. A todo list manager could be useful to a college student managing assignments, an office worker managing tasks, a parent managing errands, or a supermarket shopper managing a shopping list. We may wind up with slightly different variations for different kinds of users. For example, we may add price and quantity fields for shoppers. For college students, we may add a field for the due date of an assignment.

Another important thing to consider is that the role can change over time. We may start out with an app geared toward college students, then find that it has become popular with office workers. BDD can help us to evolve our feature and its justification as our app's users change.

For now, let's choose the role of the office worker, since that fits the use case of a generic todo list well.

Now, let's move on to the value proposition. The role of office worker can help us right away to make this part more specific. For an office worker, the todo list is a way to make sure that all tasks get done. Another important value is knowing what has not been done. If we had chosen the role of college student, we would have had to also consider due dates, which tend to be much more rigid in academic environments than in companies. We can also imagine that the office worker's manager may be interested in the todo list, but in a different way. For the manager, the todo list provides value by showing how efficient the office worker is, so aggregate values such as number of tasks completed and percentage of tasks completed are more important. We can see that reflecting on the role and the value proposition can shed a lot of light on what we develop and for whom.

We won't go into the actual decision of which is more valuable. That is a difficult and context-specific topic, and as we mentioned earlier, it is not realistic for this kind of judgment to always be embedded explicitly in our BDD spec.

Here's what our updated MMF looks like:

As an office worker
In order to make sure I finish all my tasks for the day
And in order to know which tasks are still outstanding
I want to add todo items to a list
And I want to mark them as completed

One last note before we move on to writing our actual specs. We could have moved the second value proposition into a feature at the end. This kind of issue comes up often when dealing with BDD. It is really a matter of emphasis and the level of generalization we are comfortable with. Here, I've chosen to highlight the value of knowing which tasks are not yet finished. If the feature itself was something special, we could have highlighted a feature that would show unfinished tasks instead. Again, this is an area where there aren't obvious right or wrong answers.