Projects to products: How to ensure your agile team delivers real value
Get up to speed fast on the techniques behind successful enterprise application development, QA testing and software delivery from leading practitioners.
How AI improves microservices testing automation
App modernization 101: Understand your options—and how to get started
6 rules for high-quality page object patterns
Why you should build accessibility in from the start
9 open-source service meshes compared
Software development and IT operations teams are coming together for faster business results. Learn from enterprise dev and ops teams at the forefront of DevOps.
Shift your DevOps into high gear: Key models to consider
10 companies killing it at DevOps in 2020
Continuous delivery: What it is, and why it matters
Are poor team interactions killing your DevOps transformation?
SAP S/4HANA app migration: Lessons from the trenches
Trends and best practices for provisioning, deploying, monitoring and managing enterprise IT systems. Understand challenges and best practices for ITOM, hybrid IT, ITSM and more.
5 ways a service mesh can better manage app data sharing
15 AIOps resources for IT pros
Machine learning and data warehousing: What it is, why it matters
Get started with ESM: 5 breakout projects to consider
AIOps essentials: What it is, why it matters
All things security for software engineering, DevOps, and IT Ops teams. Stay out front on application security, information security and data security.
Preinstalled mobile malware steals money in emerging markets
Zero-trust security: How to get started
How to build in app sec with strategic automation
Secret Service dodges location-data warrants … there’s an app for that
The state of cloud security and privacy: 5 key trends to watch
Technical conference highlights, analyst reports, ebooks, guides, white papers, and case studies with in-depth and compelling content.
Chaos Conf 2020
TechBeacon Guide: Transform Your IT with AIOps
INSPIRE 20 Podcast Series: 20 Leaders Driving Diversity in Tech
TechBeacon Buyer’s Guide to ESM Products
TechBeacon Guide: Cloud Security & Data Privacy
Many teams are decomposing their work into a hierarchy of epic, feature, user story, and task. The Scaled Agile Framework (SAFe) has made this hierarchy popular, but many teams that have never looked at that model are using the same structure.
The idea is great. Epics produce big valuable products or big valuable changes to products. You decompose them into smaller chunks of value so you can deliver solutions to your customers sooner than waiting for a big-bang solution at the end.
Features are decomposed into high-value stories, which, according to definition, should provide value in production as well, and again it occurs faster than building a whole feature.
But there is a hidden anti-pattern in the way teams are decomposing 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.
Here’s how to make this critical switch in thinking.
Here’s the epic-feature-story hierarchy:
Badly written stories have been around basically forever. The two most common poor-stories patterns are horizontal slices and lifecycle slices. Here are two examples:
There are many reasons these are poor stories, but in the context of WBS and VBS, the key problem is that they are items of work, not items of value. (There are many resources for how to write great user stories, so there’s no need to repeat that here.)
WBS has been used to plan development work for a long time, so it is deeply embedded in our muscle memory. And when we were project-driven, this was a great technique.
But with the movement away from project culture and toward product culture, this technique no longer works well. You need to think in terms of product delivery.
Here are two exercises to help people reframe agile development as a VBS instead of a WBS.
In this exercise, you ask the team to articulate, at a high level, what it is building. Note that you’re not listing the steps to build it (that’s WBS) but instead are describing what it is (VBS).
Let’s imagine the team says you’re building four things:
The answer could be a list such as the one above, or it could be a one-sentence answer such as “an autonomous vehicle.”
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 rigor to ensure you have thought through the risks and have the best chance of success.
Additionally, every epic, feature, and story creates or modifies a product. That is the link to products in the “projects to products” journey.
Keep in mind that this is just a first estimate. So you need to decide based on the following guidelines:
Here’s shorthand for the same thoughts:
Keep that shorthand version handy for the next step.
Looking at the list you created in Step 1, simply ask: How long would it take to deliver this value to production? >1Q? >1S? <1S?
Then simply assign the correct type to the piece of value! Just like that, you now have epics, features, and stories in your backlog. Notice that you did not worry about this when you made your list of value.
Also, notice that your backlog has all three types in it, but so far there is no hierarchy. The work items are epics, features, and stories that started as those types without any upward traceability.
This can make some people uncomfortable. Some feel that if a story or feature doesn’t trace to an epic, there is no container proving that the story or feature is valuable work. 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 they are associated with.
Remember that all three types either modify or create products. In Azure DevOps, all of the stories, features, and epics use the “area path” field to designate what product they are affiliated with. And by doing that, you are linking all value delivery work to the products they create or modify.
In Jira, on the other hand, you can use “components” to represent the product that the work belongs to.
Whatever tool you use, don’t worry about tracing upwards. Just ensure that every epic, feature, and story traces to a product. And if you are using SAFe, how those products are funded and how those funds are used is decentralized by tying all epics, features, and stories to the funded products.
At this point, 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.
In the above example, perhaps W and Y were features due to size. X is small enough to do in one sprint, so it’s a story. And perhaps Z becomes three epics. There is no hierarchy here, just a pile of different size work to do.
While all items do not trace upwards, big items such as epics and features need to be decomposed so they can be prioritized with the other lower-level work that doesn’t trace upwards.
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 decompose them, you do not decompose them 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 decomposed to the story level.
Stories do not decompose into smaller value; you can decompose 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 decomposed into features. Every feature is decomposed into stories. And all of them are value chunks, not tasks. And thus you have a VBS instead of a WBS.
Some things in the original list of items were small enough to become features. Others were small enough to be stories. None of those trace up to a containing epic or feature if they started life smaller than that.
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. It is almost like story point estimation, but at a much larger, easier level.
For teams with an existing backlog that’s more WBS than VBS, this can be quite easy to repair.
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 story board 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 X” 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 V,” for example: Refine your understanding of it. Develop it. Test it. Deploy it. Done! Value to the user is achieved. But when “test component X” moves to done, direct user value has not been achieved.
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.
Other Kanban state changes can be educational as well. Which epics moved into MVP delivered, testing the hypothesis now? Which features were pulled from the backlog into implementing? And so on. 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 slides. It is a beautiful thing!
Many people see their agile work management tools as a hierarchy of epic, feature, and story. And the muscle memory of a WBS is so strong, they overlay their WBS into the containers of epic, feature, and story.
Instead, focus on products, sub-products, and value delivery. Refactor 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 quarter. Features require more time than a sprint. Stories are done within a sprint. And all are value delivery items in a VBS.
Get up to speed on using AI with test automation in TechBeacon’s Guide.
Find out the top four benefits of AI-powered testing in this Webinar.
Learn best practices for reducing software defects with TechBeacon’s Guide.
Download the free report “Agile and DevOps Reduces Volume, Cost, and Impact of Production Defects”.
Practice quality-driven development with best practices from QA practitioners in TechBeacon’s Guide.
Download the free World Quality Report 2019-20.
Get the best of TechBeacon, from App Dev & Testing to Security, delivered weekly.
I’d like to receive emails from TechBeacon and Micro Focus to stay up-to-date on products, services, education, research, news, events, and promotions.
Check your email for the latest from TechBeacon.
Projects to products: How to ensure your agile team delivers real value
Research & References of Projects to products: How to ensure your agile team delivers real value|A&C Accounting And Tax Services
Source
0 Comments