Category: Design

Building valuable products: Remote agile teams

Numerous teams are constructing their work into a hierarchy of epic, feature, user story, and task. Using the Scaled Agile Framework (SAFe) has made this hierarchy popular, but many other teams are following that model using the same structure.

Epics provide big valuable products or big valuable changes to products. You construct them into shorter pieces of value so you can deliver solutions to your users sooner than waiting for a killer solution at the end.

 

Features are constructed into high-value stories, which, according to the definition, should provide value in production, and again it occurs faster than building a whole feature.

 

But there is a hidden pattern in the way teams are constructing work into an epic-feature-story hierarchy. Teams use agile tools to manage epics, features, stories, and tasks. But they too often use them to articulate a work breakdown structure (WBS) instead of a value breakdown structure (VBS).

WBS refers to the common, age-old project-management practice of breaking tasks into smaller chunks, allowing teams to estimate time and costs for completion. VBS, instead, focuses on product delivery and sub-products, not tasks and sub-tasks.

Please follow us to detail our findings in building valuable products.

Old thinking ways result in poor user stories

WBS has been used to plan development work for a long time, so it is deeply embedded in our brains. And when we were project-driven, this was a great practice.

 

But with the agile movement for project culture and toward product culture, this method no longer works. You need to think in terms of product delivery and product value.

Rewire your brain

Here are two ideas to help people reframe agile development as a value breakdown structure (VBS) instead of a work breakdown structure (WBS).

 

Method 1: Really understand what you are building, and why…

Here, ask yourself and the team to articulate, at a high level, what they are building. Note that you’re not listing the steps to build it (that’s WBS) but instead are describing what it is (VBS).

 

Collaborate to create a list of what you are building

Let’s imagine the team says you’re building four things:

  • A new report here
  • Modifying an existing report with X
  • A new detail view with a graph for Y
  • Bringing function Z, from older version to newer

The answer could be a list such as the one above, or it could be a one-sentence answer such as “an space ship.”

 

With the team decide whether it’s an epic, feature, or story

In a VBS, epics, features, and stories are the same thing: value delivery. It’s just that each has different rules and syntax due to each having a different level of risk.

Epics are highest risk, features are less risky, and stories the least risky. So epics require more precision to secure you have thought through the risks and have the best chance of success.

Additionally, every epic, feature, and story creates or modifies a product.

So your team need to decide based on the following guidelines:

  • Epics are value that will be delivered to production or be production ready in more than two months.
  • Features can be delivered in a sprint.
  • Stories can be delivered in less time than a sprint.
Group similar types with their product value

Simply ask yourself “How long would it take to deliver this value to production?”

Then simply assign the correct type to the piece of value! Just like that, you now have epics, features, and stories in your backlog.

 

Look at the blocks

Some believe that all valuable work must be visible from the epic level, because the epic level (in SAFe) is also the portfolio level. And the portfolio level is where you make financial decisions about work.

 

But this is not actually correct. All three types—stories, features, and epics—are about value. The goal is to decentralize value decision making and push it downwards, where the risks are low. Stories and features are small, and the product owners and product managers are trusted and empowered to prioritize those types of work.

 

People can also feel as if these stories and features are “orphaned” if they don’t trace to a higher-level container. But, in fact, they do trace to a higher-level container: the product value they are associated with.

 

Remember that all three types either modify or create products. Just ensure that every epic, feature, and story traces to a product.

 

Team work and break down all features and epics

You might have a pile of epics, features, and stories that need to be built. If all of the work is small, you may have only stories. If all the work is big, you may have a list of epics. Or you may have any combination, strictly based on the size of the work. There is no hierarchy here, just a pile of different size work to do.

 

Big items such as epics and features need to be decomposed so they can be prioritized with the other lower-level work. You can do this by asking, “What is a smaller piece of value we could do more quickly than this whole thing?” And as you de-construct them, you don’t do it into tasks but into value items.

 

And once you decompose features and epics into smaller value chunks, you once again ask, “How long would this take to put into production, or to make production-ready?” And again you give them the appropriate epic/feature/story type. Repeat this until every epic and feature has been disintegrated to the story level.

 

Stories do not disintegrated into smaller value; you can disintegrated those into tasks. Note that tasks are the only element in the hierarchy that are like those found in a WBS. They are tasks, not value chunks.

 

In other words, the epics, features, and stories are all value chunks. The tasks are tasks, and they are optional.

 

Eventually every epic is separated into features. Every feature is separated into stories. And all of them are value chunks, not tasks. And thus you have a VBS instead of a WBS.

 

Now the story backlog

So at the story level, you will have a bunch of stories, some of which are standalone, some that trace to features, and some that trace to features that in turn trace to epics. But all stories can now be prioritized against one another.

 

And if they do trace upward, that will be considered during sprint planning. You want to finish a whole feature if possible, so a high-priority feature would increase the priority of the stories as well.

 

Bottom line is that epic versus feature versus story is simply a first-level guess at the size of the effort to deliver value.

Method 2: Adjusting an existing backlog

For teams with an existing backlog that’s more WBS than VBS, this can be quite easy to repair.

  1. Grab the current list of epics, features, and stories and leave it open in the background.
  2. Notice there is a mix of some items that are WBS tasks, and some that are products or value of the VBS type. It is common to have a mix of both styles.
  3. Extract the products or value, and create a fresh backlog with only value delivery items.

To accomplish step 3, take a task-style backlog item and ask, “What product or sub-product does this create or improve?” The answer will be the real VBS item that should be in your backlog instead. If you can’t figure out the answer, then why would you do that task?

 

The third step can be fun and satisfying for your teams. Their new epics, features, and stories are true value work items. Each work item needs refinement, development, test, and deployment. Each is valuable to users.

 

Imagine that your storyboard columns were “refine, develop, test, deploy, done.” Notice that a WBS task-style story doesn’t work on a board such as this: “test component Z” would make sense only in the test column, rather than flowing through them all.

 

Value-type VBS stories, on the other hand, flow through all of this. “New finance report X,” for example: Refine your understanding of it. Develop it. Test it. Deploy it. Done! Value to the user is achieved. But when “Test component Z” moves to done, direct user value has not been achieved.

software-team
Real value on delivery

Once you move away from a WBS to a real VBS, you can easily report on value delivery. Which epics closed? That is value delivery. Which features closed? Value delivery. Stories? Value delivery.

 

So your value delivery reports can simply be reporting on work items closed. And it only works if the work items are real value delivery items, not work breakdown tasks. If every item is a value delivery item, these reports are satisfying and informative.

 

If someone wants a report of value delivery for their dollars, they can now show their recently done backlog and answer that question by just using their work management tools instead of creating PowerPoint presentation. It’s a beautiful and better way!

 

 

Change your focus to value

Many people see their agile work management tools as a hierarchy of epic, feature, and story. And the WBS mindset win, they fit the WBS into the containers of epic, feature, and story.

 

Instead, focus on products, sub-products, and value delivery. Refine and adjust existing backlogs by separating tasks from value. Think of the epic-feature-story hierarchy as nothing more than a first estimate on time. Epics take more than a three months. Features require 1 sprint. Stories are done within a sprint. And all are value delivery items.

Digital Transformation With Design Thinking

Digital transformation is reinventing business practices.

Now a days technological capabilities are continuously making upgrades and in order to stay ahead, businesses must be agile and innovative in creating new methods as they incorporate these digital technologies into their business practices. To stay competitive in any market, having a digital transformation strategy is fundamental.

The change from business to digital is not usually easy to start with, our digital environment changes quickly and variable. Staying up to date can be challenging and leave many in doubt in how to proceed. This is where design thinking comes in.

Design thinking is a five step, design methodology that does not present a solution at first but reviews both present and future details of a problem and searches for different solutions.

Digital transformation presents issues that are complicated and unspecified. So using design thinking to take in your organization’s digital transformation helps deal with these problems by interacting with consumers and come up with solutions.

Design thinking is made up of five steps: empathize, define, ideate, prototype and test.

 

Empathize

A fundamental element to digital transformation is making an excellent experience for the customer. In order to achieve this, it is important to relate with them, to comprehend their inspiration and needs.

The problems we are solving are not often our own, so we shouldn’t presume to know how the customer will act.

Instead take a look as they interact with you service. Take note of what they search in Google or on the site, study click-stream data to see how they are interacting with your site or app, review chat logs to see what they are asking customer service reps, or even make surveys with your customers to ask them questions of what they want the digital experience to be.

Also, very important is field trips to what how customers interact with current alternatives, how they solve their needs, from observation one can learn a lot.

To really understand where the customer’s friction points are along the digital journey will help you with the information you need to solve their issues.

 

Define

The define stage brings transparency to the problems you are trying to solve. What you have learned from the empathize stage will help you find where you need to focus your time and energy.

After exanimating this information, it’s time to create a problem statement. The problem statement should be focused on a specific issue and adjust toward the user. We are trying to help our customers because we want them to have a good experience.

This stage can be challenging because you will find many problems that need attention. However the point of this phase is not to overwhelm, but to help prioritize them into individual, and possible opportunities.

 

Ideate

Now that we have the definitive problem, It’s time to create some ideas in how to fix it. In this phase it is important to brainstorm by using a group of persons in order to develop a variety of creative ideas. You shouldn’t be overthinking or coming up with one solution. The Ideate phase is quick, creative and collaborative.

 

Prototype

In this step the team will experiment with diverse types of inexpensive and simple models to quickly target and validate your solution ideas. Prototypes should be tested in a small group.

Observe the way people interact with the prototype, then get feedback and use this information to change and improve the next model. This phase should be very quick with efficient improvements. Create a safe environment where it is Okay to fail and learn from those failures to continually progress.

At the end of this phase, you should know what works and what doesn’t and how the customers feel when interacting with your service.

 

Test

Constantly testing your prototypes is an opportunity to improve. Every interaction with a customer is an opportunity to learn and improve the customer service. In the testing phase, you recollect information from the previous stages in the design thinking process.

The quest for better customer experience is never ending. We should be constantly testing to come up with new ideas to improve and add value to our provided service.

I’ll explain more in depth in future post, what is Minimum Valuable Service, or MVS.  Lightly different from MVP or Minimum Viable Product

In the world we live today, using digital transformation for all business practices is a must, and design thinking methodology is a practical way to tackle the issues this transition presents.

Either you follow the stages above or discover your own design thinking processes; using these methods will help your company incorporate digital technologies and innovate.