Beyond User Stories

By: Marcello Farina, Senior Product Manager

Starting as a product manager, among the strange creatures encountered on your path are so-called “user stories”. These usually appear as one-liners on product requirement documents and look like this:

“As a [User] I want to do [Something] in order to [Achieve some other thing]”

A vast amount of literature on user stories, how to write them and why they are useful is widely available, so there is little value in digging into those details. However, I believe it’s important to go through the reasons that they are a good tool to manage product development, but also to point out where they fall short; at least, for some type of products.

The good

Let’s look at the reasons why user stories can help build the right product:

• User stories are user-centric
• User stories provide an overview on what is needed
• User stories help prioritize functionality

User stories are user-centric

User stories are obviously about users! They describe:

• Who is this feature supposed to help?
• What are the user’s characteristics?
• What is the role of this specific user in the bigger scenario of the product?

Every story needs to be tied to a user. If the product manager cannot describe a user for the feature, then why build it in the first place?

User stories provide an overview on what is needed

The details in the user story describe what the user is supposed to be doing and in order to achieve that, it should provide a clear understanding on why a feature should be developed.

Understanding the problem we are trying to solve is a key step to developing a solution. Details of the user’s motivation and the expected outcome will drive the solution design.

User stories help to prioritize functionality

Each user story describes a single feature solving a user problem. Having a list of features helps in deciding which features are needed initially and which can come later to produce a minimum viable product. (What is the Minimum set of things that users should be able to perform in order to achieve a Viable outcome for the Product that we are building?).

Which features can come later? What is the best order to develop the features described in the user stories? A good list of stories written down will help to start a prioritization discussion with our stakeholders which eventually creates the product development roadmap.

So far so good! User stories seem to be a great place to start. However, let’s see some of the challenges which the R3 product team has faced when dealing with the limitation of a “user story first!” approach.

The not-so-good

One of the first things I realized after joining R3 as a product manager was that I was dealing with a special type of product. Corda in fact is a platform which allows you to run customer applications called CorDapps. Corda is an application for applications and this complicates things quite a lot. Let’s see how!

A galaxy of prerequisites needed to start developing a story

Consider the simplest user story one can imagine in Corda, such as:

“As a CorDapp developer I want to deploy my CorDapp in order to run it”

This user story requires, in order to be developed, a large amount of preparation tasks which are not meaningful or should not be exposed to the user, such as:

• Create a schema in the DB
• Assign default admin users to the app
• Store the app JAR file somewhere
• …and so on.

So a simple story requires a large number of such tasks to be performed. Can these tasks be described as user stories as well? In some cases, yes. In other cases, it doesn’t really make sense or doesn’t add any value for the person reading the story.

So does it make sense to list these tasks as user stories? Is there a better and simpler way to document these tasks which focuses only on describing what needs to be done? We found out user stories were falling short here and were not helping. On the contrary, they were confusing. We needed to find something more in line with our needs.

Incremental development

We’ve seen how it’s common practice to start scoping product design by selecting stories for the MVP and then keep improving the product incrementally by adding features according to the roadmap prioritization. Developing Corda, we realized how big stories can get. At a granular level, we had difficulty surfacing what needs to be done if looking at these features only from the user’s point of view. A granular list of tasks can help in deciding what can or cannot be descoped, what must be prioritized and what can be delivered later.

A typical example where a result can be achieved faster by reducing the scope is hardcoding a specific value rather than making it configurable. Hardcoding is faster, while making something configurable is more complex. Configuration of that value can be added at a later stage. This approach also allows us to gather feedback earlier: does the customer really need that value to be configurable? The only way to know if by letting them try it out!

Again, could this be done with user stories? Yes! Does it add any value? Well, that depends. In my experience in R3, I noticed flooding the backlog with stories was not really helping in achieving things faster.

Beyond user stories

In my early days at R3, I put together the high-level user stories for Corda 5 and got them reviewed by the platform architects. I gathered their feedback, updated the user stories where needed and proudly presented the PRD to my colleagues.

It was a beautiful, rewarding moment…. which faded away quickly when I realized how difficult it was to map what the engineering team was building to my stories. All the limitations I described above popped up simultaneously and I quickly understood we were far from done. We needed a way to go beyond those stories and get control and visibility on what we were doing. We had to find an R3 way for the product development of the Corda platform.

Introducing milestones

Milestone is a term borrowed from Waterfall terminology, and considering I’m an Agile Scrum Certified PO, the first time I heard the word during a meeting with the senior management, it made me shiver! But whichever word we decide to use to describe it, the model we introduced proved to be quite successful and I believe it might be interesting to give you a quick overview on what we’ve done.

What milestones are

In R3 Corda business unit, by milestone we mean a phase of the development project involving one or more teams focusing on achieving a specific, demo-able goal within a defined timeframe.

The scope is defined by:

• Product managers: owning what needs to be done (with timelines and dependencies)
• Tech leads: owning how it should be done

Items to be delivered in a milestone are mapped to the high-level user story and do not need to adhere to a specific template. All we need to know is what developers are supposed to build. As long as everyone understands it, it’s good enough.

Why we use milestones

There are a few reasons why we believe organizing work in milestones has proved to be useful in our case:

1. It gives a sense of completion
   Focusing on the outcome within a timeline, milestones give a sense of pace to the developing teams. When reasonably achievable, milestone deadlines help us to focus on a goal. Completing something in time for a scheduled showcase and being proud of it can be really rewarding.
2. It helps in showcasing to stakeholders
   At the end of every milestone, the deliverable should be in a ready-to-demo state. Dealing with stage-fright of demos and Q&As is both rewarding and challenging for everyone involved and end-of-milestones showcases give the whole organization the feeling that things are progressing.
3. It helps when building and maintaining demo CorDapps
   A realistic demo CorDapp is an ideal tool to keep a showcase audience interested. We go back to the initial value of user stories I talked about before – we’re building a platform, but there will be applications running on it. Applications are made for users and whichever underlying technology we have implemented, the best way to prove that it works is to show a CorDapp in action. Building a demo CorDapp once and maintaining it through the platform development process milestone after milestone proved to be an effective way to test, showcase and play with the platform.

We go back to the initial value of user stories I talked about before – we’re building a platform, but there will be applications running on it. Applications are made for users and whichever underlying technology we have implemented, the best way to prove that it works is to show a CorDapp in action. Building a demo CorDapp once and maintaining it through the platform development process milestone after milestone proved to be an effective way to test, showcase and play with the platform.

Introducing tech epics

I briefly mentioned tasks contained within milestones. These are where technical items are listed and described. The scope of a milestone is defined by the tech epics it contains. In R3 we call them epics because the tickets are linked to smaller tasks which can be picked up by a single developer.

This approach provides granular visibility on the actual technical content which will be worked on and it needs to align with the milestone goal.

Granular visibility on development effort

All product managers face questions such as “when are we going to get it?” and “how long will it take?”. The milestone/tech epic approach helps them to give informed answers based on data:

• Sizing: Tech epics (which represent a solution) are closer to actual work than user stories (which represent a problem). We’ve noticed that sizing tech epics is more accurate and easier to express than sizing stories. When a task proves to be bigger than expected is easier to spot it and take actions like splitting, postponing, descoping, going back to the drawing board to find a different solution.
• Dependencies and blockers: Multiple teams work on tasks related to different aspects of the product. How can we be sure that they will coordinate effectively? How can we prevent Team A being blocked by Team B not having finished something that Team A is dependent on?

Once the epics for a given milestone are agreed, it’s easier to highlight dependencies in a project plan so that teams can focus on unblocked items and strategically tackle dependencies early to avoid blocking other teams’ work.

Conclusion

We’ve seen how Corda development started by defining the new version of the Corda value proposition and writing user stories which would deliver it. We’ve also seen how we’ve arranged the deliverables using tools like Milestones and Tech epics just because they work better for a complex platform like Corda and an organization like R3 Corda Business Unit.

This is the story so far, but what will happen next?

Back to user stories

With the development of Corda 5 approaching General Availability phase, the Corda product team will be able to focus again on the user stories raised at the start of the project. To agree on what’s coming next from a technical perspective, we must first look at what our customers’ needs will be in the next phase.

At that point it may be interesting to try segmenting users based on platform usage by early adopters. New stories should describe the behavior of different personas belonging to the same group of users.

We’ll work to identify users such as:

• Node operators from different types of organizations: small start-ups, large organizations, or platform providers
• CorDapps developers: building PoCs, building resellable CorDapps, or in-house solutions.

We’ll also look at mapping use cases based on user organizations’ characteristics such as:

• Size of deployment
• Business domain
• Number and frequency of transactions
• Geographical distribution of network participants

Segmenting user and business characteristics will help to build a more detailed set of requirements tailored around a more specific set of personas and use cases and therefore more effective. At that point user stories will come in handy again to start the next development cycle.