Writing Better Features in SAFe

This page provides a summary and recap of the Webinar: Writing Better Features in SAFe that took place on the 1st August 2024. It contains a video replay for anyone who missed it plus a transcription of the voice-over for detailed study. We hope you find it useful.

Webinar Synopsis

Exploring the behaviors that need to be encouraged to get better Features!

A single backlog of work shared by many people focuses and aligns their work towards the most important work items. In SAFe, an ART Backlog of Features is used to align the work of multiple teams in the ART to the most important work items. However there are many pitfalls that must be avoided when writing Features for the ART backlog. Bad Features will result in poor work throughput, unaligned and disempowered teams. In this webinar we describe some of the strategies you can follow when writing Features to encourage agility as well as improve productivity.

The second in a series of webinars that look at the primary backlog items within SAFe: Epics, Features and Stories.

In this webinar we’ll be looking at some of the strategies you can follow when writing Features to encourage agility as well as improve productivity.

• Epics (see replay)
• Features (this webinar)
• Stories (see replay)

Webinar Replay

Writing Better Features in SAFe held on the 1st August 2024.

We hope you find the content useful and please do not hesitate to contact us if you need any help with your SAFe implementation.

---

Video Transcript

What Are Features?

We should probably understand what Features are before we try to make them better.

Backlog Management Tooling

Before we go any further, we need to talk about backlog management tooling; particularly backlog management tooling that has been configured for small scale teams and is using the traditional definition of Epic which was a big story. SAFe Features might be Epics as far as your backlog tooling is concerned; and SAFe Epics would be initiatives. In defence of the tooling providers, the tooling is fully configurable, but many organisations either can’t be bothered to invest in configuring it, or they’ve mis-interpreted the part of the regulations that state that the teams must be following a documented process, they’ve assumed that locking the backlog management tooling is the same as following a documented process… ignorance is bliss!

The Challenge Of Scale

Figure 1: The Challenge Of Scale

Think about the big systems that your organisations are developing.

Can you deliver releasable end-customer value in the day or two that is the ideal size for a Team level user story?

Probably not.

Can you deliver releasable end-customer value in the two weeks that is the recommended size for a Sprint, an Iteration, at the Team level?

That can be hard as well.

But stories have to fit within an Iteration and if they won’t in two weeks then we’re going to have to make our Sprints, our Iterations bigger! Is that the right customisation to make?

Probably not.

The longer the iteration, the less feedback the team receives. That’s going to be compromising a whole bunch of principles from both the Agile Manifesto and SAFe’s own Principles.

The fix is not to increase the timeboxes but to introduce a level of aggregation, this is where Features come in.

They can represent releasable end-customer value whilst allowing the stories to remain small increments to track progress and generate rapid feedback on what’s been done. To be clear, Stories are still end-customer deployable value, but they don’t have to be releasable in their own right; Features become the release points. Stories might be individual buttons on a webpage that the customer wants and expects, but it makes no sense to release them until there are sufficient buttons on the webpage to allow the customer to achieve something useful, the Feature would capture what that useful thing is.

Potentially Releasable Points

Figure 2: Potentially Releasable Points

If Features are potentially Releasable Points, then they need to contain all the work to make the Feature releasable, and releasable is more than just doing the engineering.

Has the documentation been updated? User manuals. Internal technical documentation for those poor engineers that come after us. Regulatory and compliance paperwork. Nobody like’s doing the paperwork, but it’s got to be done and someone has to do it!

Have the bigger tests been done? An end-to-end test isn’t necessarily going to arise as the sum of all the unit tests on the stories that made up the Feature, it might need to be created explicitly. There may be tests that aren’t economically viable to run on a per-story basis but should be run on a per-feature basis. Exploratory tests that require human input such as security tests. Test where there are resource constraints; my personal experience is with network stress tests; these have to be done on a separate network and there may only be one network for doing these tests. You don’t do them on the corporate network because they’re designed to test the network to the point of collapse and in my experience bringing down the corporate network tends to be at worst a career limiting move, at best an awful lot of explaining.

What about the things that we know we need to engineer in? Logging and metrics in the code, debug headers and measurement points would be the equivalent in electronic design, for mechanical engineering it would be maintenance access, lubrication points, service functionality for easily replacing parts that regularly wear. The business might not request this but the engineers need to remember it because they’ll be responsible for maintaining these systems in the future.

Definition-Of-Done for Features, or a System or Solution Increment as Scaled Agile refers to it, lists all the extra work the engineering teams need to consider. Use it as a tool during planning to help influence the creation of Stories. I say potentially releasable, because whilst the engineers should be doing everything in their power to ensure that a Feature leaves the system in a releasable state, the organisation might choose not to release the Feature immediately. It becomes a business decision to release when the customers are ready, or to align with other activities such as market events like an advertising campaign or market rhythms like the holiday period.

That’s all the practicalities of the engineering to get a Feature released, but way back at the very beginning, when the Feature is written, write it as something that can be released; not just a piece of work to be done. Remember the value may be internal as much as it is external, Enabler Features building prototypes, running experiments they’re releasing knowledge to the organisation to manage risk, make decisions and plan better in the future. Enabler Features building architecture or infrastructure are releasing internal value to the organisation so that it can build the external, end-customer, value better, faster in the future.

Feature Constraints

Figure 3: Feature Constraints

Features are constrained to the Planning Interval, the timebox that an Agile Release Train uses to manage planning, execution and governance. Would you want one Feature that fills the whole of the Planning Interval and take all the Train’s time and effort?

No.

You’ll never get it delivered, something will go wrong and there’s no value if the Feature is incomplete. The Agile Release Train should be tackling a number of Features within the Planning Interval, but don’t go too far the other way, don’t make the Features so small that they’re really Stories. If you can release individual Stories and each story is true end-customer value, then you don’t need to scale. Always, always remember that the First Rule Of Scaling is Don’t.

Features are constrained to the Agile Release Train. Whilst they must be deliverable by the train, many teams may be collaborating to deliver the Feature, this scenario is particularly likely if the teams are complex sub-system or platform teams, the end-to-end Features will span across the teams.

Feature Lifecycle

Now that we’ve seen what Features are: potentially releasable pieces of customer value, a quick look at the journey they go on to become releasable pieces of end user value.

Figure 4: Feature Lifecycle

	Requested: someone has an idea for a feature, simply captured as a title and benefit to keep the barrier to entry low. Maybe an initial estimate so that it can be used in forecasting and road-mapping. No more detail than that.
Ready: is where the detail gets added to get the Feature Ready for PI Planning. Don’t waste effort elaborating Features that aren’t needed for the next PI Planning event, focus on the ones that are in the next PI Planning event.
	Committed: In PI Planning the teams have created the stories that will realise the Feature and raised their hands to commit to the plan.
Previewed: Try to demonstrate the Feature as early as possible. That demonstration can be used to solicit feedback to steer the Feature towards completion. If you only demonstrate at the end, you can never be quicker because you’ll never realise that you didn’t need everything!
	Accepted: The business, represented by the Product Manager, is happy that this Feature fulfils the needs of the Business. Assess the value, not completion of the work, you might have achieved the value without completing all the work that was identified in planning, or the work may have evolved during delivery.
Released: Important because once it’s in the hands of the end-customers we know that we can start measuring to see whether the benefit hypothesis has been proven.
	Successful: The benefit hypothesis has been proven. If the metrics show that it hasn’t been successful, then scientific method can turn that knowledge into a benefit because we now know what the customers don’t want and can avoid doing the same again in the future.

The states that a feature goes through are not the process. The states are universal, applicable to all, but your process is yours. You may have many process steps to get the Feature to the next state, you might have just one. You should be evolving your process, changing it to suit your reality, but even as the process evolves the underlying states remain universal. By talking about the underlying states, we avoid getting caught up in everyone’s personal interpretation of the process. This has been discussed in a previous webinar Essence and SAFe - Pieces Of The Puzzle.

Whilst they do have a lifecycle, the title of this webinar is Writing Better Features, which focuses on the Suggested and Ready states.

Let’s explore where Features come from…

Don’t Interpret The Hierarchy Literally

Figure 5: Don’t Interpret The Hierarchy Literally

If you interpret the diagrams literally, and some people’s brains are wired for literal interpretation, then Features come from Epics. The Epic Owner dictates to the Product Manager what the Features are. It is from this that some of the criticisms of SAFe arise, perhaps the critics are very literally minded. It doesn’t have to be a dictatorship, although this is what many organisations fall into because they’re recreating the old behaviours within the new system rather than using the new system to encourage behavioural change.

Ideally the Product Manager responsible for the backlog of Features would be empowered with the responsibility for the Product and everything associated with the Product. That’s why the Advanced Product Management course that Scaled Agile provides talks very little about SAFe but instead covers techniques for interacting with customers, talks about viability and sustainability of the product and pricing strategies. True product ownership.

The Product Manager is engaging with the customers and facilitating the Product Owners within the Agile Release Train to engage with the customers too. Collaboratively, as the Product Management Team, they own the Product. Therefore, the Product Management Team is best placed to understand the customer’s needs and should be soliciting ideas from Features from the customers. This is the sort of Product Management / Product Ownership that Marty Cagan encourages, he doesn’t like SAFe, perhaps he’s interpreted the diagrams too literally, but the only thing stopping the Product Management Team from being truly empowered is the will of the organisation, and that’s true regardless of whatever framework is being utilised. Without wanting to denigrate anyone currently in the Product Manager role, often organisations put an individual in place as a proxy rather than the person that is ultimately accountable for the product and of course that creates an extra layer of communication that doesn’t need to be there.

If we’ve empowered our Product Managers to truly own the Product, then what of Epics and Epic Owners?

Figure 6: Empower Product Management to work out how to hit the targets

The Epic provides the intent for a change to the business, the Epic Owner is communicating that intent.

The Product Management team can work with the Customers to solicit Features that would fulfil that intent. As those Features are released the metrics on the Epic should prove whether they have fulfilled the intent of the Epic and influence the Product Management team’s conversations about what should be done next. It’s not just the Epic, the Portfolio Vision provides intent as well. An organisation can’t blindly do whatever the customers desire, the customer requests need to be compared against the vision for the organisation to ensure that the organisation is viable into the future.

SAFe Principle #8: unlock the intrinsic motivation of knowledge worker. Knowledge workers know more about doing their work than the management do, this statement also applies when you look at the hierarchies within SAFe. Better Features arise from the people creating them being the people that know the Product, being the people closest to the customers and interacting with them continually. Product Management should know more about their specific Product than the Portfolio.

SAFe Fellow Ian Spence, wrote a series of blog posts on Preparing Features For PI Planning.

Connect With the Customer

Figure 7: Connect With The Customer(s)

Connect with the customer. It’s a step in the Business Agility Value Stream, it’s on the Responsibility Wheels of Product Managers and Product Owners and it’s an absolute necessity if the organisation wants to be Customer Centric.

Features can have many customers. The users are one customer for sure, both external or internal, but there can be others.

Regulatory bodies. If the regulators needs aren’t satisfied then the users needs are irrelevant because the product won’t be allowed to reach them.

The engineers within the team or train are also a customer because they are the recipients of their own work, they need to take it and maintain it, or build upon it to create new functionality.

This isn’t a webinar on Design Thinking Techniques, and I’m fully willing to raise my hands and admit that whilst I can do it, I’m no expert on Design Thinking Techniques. The details of how you interact with the customer, how you get their needs from them and into the Feature, that is for you to work out. Different customers, even to the same feature, may have different interaction patterns and require different engagement techniques.

The list above is illustrative rather than comprehensive, you may have other classes of people that are potential customers of your Feature(s).

That those needs have been found, from all of the different customers, is what’s important.

Know your Product

Feature Driven Delivery is a great idea, it tries to get development teams to think about units of releasable value, generally focussed on customer needs, but Feature Driven Delivery has its own challenges.

If you just start piling up Features without thought as to how they fit together then you will encounter problems. Feature orientated teams, we love them because they get stuff done quicky by minimising hand-offs and collaborations, but if they’re all operating independently, doing things their way then the internal structure of the product is going to be a mess.

Big Up-Front design is dumb… but no up-front design in dumber.

Dave Thomas,
Agile Manifesto Signatory

Know your product, know where your product is trying to get to. The vision for the product, both business and technical.

Then you know where you Features fit and how they interact with each other both from business and technical perspective. When you have teams collaborating, which is what Agile Release Trains are for, then there needs to be a common strategy and the discipline to follow that strategy. The strategy doesn’t have to be decided by a single person, the Product Manager, or the System Architect, it should be a collaborative decision which allows everyone in the Agile Release Train to participate.

Many minds minimise mistakes

I always adore an alliteration.

Figure 8: Many Minds Minimise Mistakes

Design Thinking has solicited the ideas for Features, those that are going to be taken into the next PI Planning need elaboration so that everyone understands what the challenge represented by the Feature is. Those that aren’t going into the next PI Planning can wait their turn, no point devoting effort to them right now. How do we know what’s going into the next PI? Road mapping techniques or comparing a sum of estimates against historic velocity.

Elaboration is best done as a collaborative activity. Every time I say collaboration, think knowledge transfer.

The elaboration of Features is done collaboratively by the Product Management, Product Owner group through them questioning stakeholders and users about what they want.

This transfers knowledge from the people, the users, that have a need, to the people, the Product Owners, that can fulfil that need by getting their team, or teams, to undertake the work to fulfil the user needs of the Feature.

That the recipients of the work item, in this case the Product Owners, create the work item is a powerful trick. It means they have to have understood enough to be able to write it down, at worst they know who the expert is and can arrange for them to explain to the team. This also empowers the Product Owners to actively participate in ownership of the product, which avoids them become mere messengers, which is another criticism of SAFe that arises from bad interpretations of the framework. Many minds, many perspectives, you’re bringing the collective brainpower of the group to elaborating the feature rather than a single individual, therefore a much greater chance of catching errors and mistakes.

But Product Ownership isn’t the only input to elaborating a Feature, there needs to be technical input as well. Architecture, Compliance, Security, UI/UX concerns, these might all have input into the Feature. Getting those inputs in early so that they steer the development is preferable to those roles acting as gatekeepers at the end and throwing work back. This early input is the Shift-Left, to earlier in the timeline, that you’ll so often hear in Agile circles. Don’t take my list of roles as exhaustive, you, or your Product Managers and Product Owners, need to work out who else should be collaborating to elaborate the Feature and invite those Subject Matter Experts along.

Collaboration is also knowledge transfer, product knowledge towards the technical people, technical knowledge towards product staff. Enough knowledge to know when to involve those with specialist knowledge directly in the conversations.

Insight into Collaborative Road Mapping Techniques.

It’s not the Words

I fell into my own trap, I started discussing Better Written Features, rather than following the design thinking trick of asking Why are Better Written Features needed? Perhaps I can make amends now.

Those of you that viewed the Epic Webinar already know where this is heading, the plot twist in the middle of the webinar… You see, it’s not the written words that make a better Feature, it’s everything behind those words and the clues have been there in the discussions about What a Feature is and Where it comes from.

Figure 9: It’s Not The Written Words, It’s Everything Behind Them

• The Feature is a piece of potentially Releasable Value, complete and ready to go.
• It is understanding the Customer Needs
• It is having a Product Strategy so that you know how the Feature fits into the Product
• Collaboration during the elaboration of the Feature has ensured that all the viewpoints have been considered, both business and technical.

Harness SAFe Principle #8, Unlock the Intrinsic Motivation of Knowledge workers.

We’ve discussed how the Product Managers and Product Owners should be empowered to discover Features that meet the businesses needs rather than the Portfolio dictating to them, that now needs to happen recursively, the Product Managers and Product Owners need to empower the teams.

Intent not Solution

Don’t tell the teams what to do, pose challenges, problems for them to solve.

Figure 10: Features Provide Intent
From: Innoversity Presents: Greatness by David Marquez

If you tell the teams what to do then they won’t think for themselves, they’ll blindly follow the instructions. They will, unquestioningly, assemble the given pieces into a plan. Congratulations, you have successfully recreated the old process, but with a new agile overhead and without any of the benefits agility brings. Why did you even bother transforming in the first place?

We are trying to empower our workforce to think. You’ve employed them as engineers, problem solvers, let’s get them solving problems, stop treating them as glorified typists. Features are problems to solve, typically new functionality the business desires in the solution, but it could be knowledge that the business needs to acquire through investigation or experimentation, it could be the challenge of improving the processes or tooling to make the organisation more efficient and effective.

Features are the What not the How. The how comes through PI Planning, through the creation of stories that change the underlying artefacts be that a code base, physical designs or documentation. This is SAFe Principle #8, unlock the intrinsic motivation of knowledge workers and the fact that knowledge workers know more about manipulating the artefacts than the management do. If the workers don’t know how to manipulate the artefacts, then you’ve got a more fundamental problem that needs solving first; we’ve all seen instances where development has been outsourced to a bunch of engineers that don’t know anything about the systems they’re being asked to develop, it’s not the fault of the engineers, it’s the fault of a management that don’t understand that managing engineering & creativity is different to managing manual labour.

With Principle #8 comes Principle #9, Decentralise Decision Making. If the teams know more about doing their work, then you have to decentralise to them, hence the screengrab of the David Marquet video. Features provide the intent to allow the teams to work out how to change the artefacts they’re responsible for.

The challenge of maintaining team autonomy within a PI Planning event is discussed in a webinar and blog series on Preserving Agility In PI Planning.

Who Is It For?

Where is the customer?

The format of a Feature is Title, Benefits Hypothesis and Acceptance Criteria, the who of the Feature isn’t explicit in the formatting of the Feature, but it should be captured.

The earlier discussion on “connect with the customer” showed that a Feature might have multiple customers, it might not be a single “who”.

Do you capture it in the Benefit Hypothesis? In the Acceptance Criteria? Or just a note on the bottom of the Feature? Ultimately, it doesn’t matter how it is recorded, what matters is that it is understood and can be communicated, verbally, if necessary, by the Product staff.

Estimation

I don’t really want to open the can of worms that is estimation, this is supposed to be a 30minute webinar, but the topic of estimation could quite happily eat up a couple of days. What I do want to talk about is the fact that there are two parts to estimation:

There is knowledge of the thing being estimated and there is knowledge of ourselves as a team, that we can solve the problems, the challenges that we will face in the future.

Many teams lack confidence in themselves, that they have the skills and knowledge to solve problems. Therefore, they want to put more and more detail into the work item to get the perfect estimate. This means solving the challenge posed in the work item upfront. Which is completely wrong thing to do when we use that estimate for do / don’t do decisions, as we do with Features. If we decide not to do something, then all that effort to create the solution for the work item becomes waste. Maybe a better approach would be to improve the team’s confidence in being able to solve problems, the best way to do that is to get them to solve problems, which they’ll never do if you keep handing them solutions.

Estimation is 90% psychology and 10% process. Why does the team want perfect estimates? What’s happened to them in the past? Did the old project managers rain hellfire on the team when they got the estimates wrong and therefore the team is living in fear? What are the estimates used for? Who are they trying to comfort or appease? Are you trying to hold people too tightly to a set of guesses about how long it’s going to take to solve some problems, problems which have inherent uncertainty in them because that is the nature of problems and problem solving?

Slam the lid down before any more worms escape! But, that little detour was important because it leads to…

Level of detail

…discussing what level of detail is needed in the Feature.

Figure 10: Positives and Negatives of More or Less Pre-Planning

The quadrants shown here are from an exercise in the Release Train Engineers course where it looks at the positives and negatives of doing more, or less, pre-planning. It’s a useful exercise because it gets people thinking, but ultimately, it’s the wrong question. It’s not about doing more or less pre-planning; it’s about doing the right preparation.

Design thinking, the double diamond. Separate understanding of the problem from designing a solution.

Feature preparation is exploration of the problem, setting the boundaries for permissible solutions, but don’t fall into determining the solution when exploring the problem. Not least because the set of people elaborating Features, mainly Product Managers and Product Owners, are not the experts on developing Solutions, that’s the Agile Team’s territory. Therefore, focus on the problem, understand the business, the customer, need. Be able to communicate those needs to the teams. Any solutioning that does have to happen wants to be very high level, primarily it’s…

Dependencies

…Dependencies.

I’m not talking about the internal collaborations within the Agie Release Train, that’s for the engineering teams to work out in PI Planning, they should know each other’s skills and areas of responsibility, and if they don’t know each other’s skills then sharing that knowledge is a great ice-breaking activity for your next PI Planning! The dependencies here are the external dependencies to third parties or other parts of the organisation. You know about these up front, or if you don’t then your system architect should.

Firstly, start negotiating with whoever is on the other side, do it as soon as you know the dependency is there because you want the information resulting from those negotiations to feed into PI Planning, if you defer it until after PI Planning it’s going to leave a plan full of unresolved risks!

If the other side is an Agile Release Train, then your Product Manager should be negotiating with that Agile Release Train’s Product Manager, negotiating features into the backlog to resolve the dependency. The features can be linked together, no need for any fancy tooling, just stick a note on one Feature referencing the corresponding Feature in the other ART’s backlog and that Feature has a note referencing back the other way. Those notes trigger conversations in the teams, they trigger one team to pick up the phone and call the other Agile Release Train to find out who has got the feature and when they’re expecting to deliver it. The notes aren’t imposing upon the teams, they are empowering them to arrange the collaborations themselves.

If the other side of the dependency isn’t Agile then it might not be possible to negotiate with them in real-time, you might only be able to get a date of when the dependency will be resolved, the Agile Release Train can plan around that date, visualise it on the PI Planning Board.

If the date isn’t within this planning interval, then there’s no point even contemplating planning any features relating to the dependency, defer them until the planning interval in which the dependency will be resolved.

If you can’t get any information back, then consider either changing the contractual relationship with the supplier to encourage more collaboration or find another more collaborative supplier. If the problems are internal, then you’ve got some fundamental organisational behaviours that need to be changed, remember everyone works for the same organisation, towards the same goals, internal competition is madness, you should be competing against your competitors, not yourselves. The end result of internal competition will always be selfishness and silos.

Slicing

Features are business needs, solicited from the customer and those customers often dream big.

Big isn’t where we want to start.

We want to start small and incrementally build up to those big dreams. Even the largest monuments are built one brick at a time. So, there is often a need to slice Features into smaller more manageable pieces.

The patterns for slicing Stories were first popularised by Richard Lawrence well over a decade ago and they have had enduring popularity.

Slicing Features is very similar but there are some differences because the resulting slices have to be valuable and releasable in their own right. Some of the tricks that you could do with Stories where you defer things until later, like security, scalability or regulatory concerns, don’t work when slicing features. Release a Feature without appropriate security in place and the internet will instantly own your system and your data. Adding security later is like shutting the stable door after the horse has bolted.

So, there are some warnings that must be heeded if you’re slicing Features.

• Don’t Defer the non-functional requirements, they have to be dealt with as part of the feature. All of the patterns are about slicing on value, because the resultant slice has to conform to the rules of being a feature, i.e. being a potentially releasable piece of value.
• Don’t slice to early, only put the effort into slicing when you know that the resultant slice is going to be a Feature in the next PI Planning. Keep the big dream whole, slice a piece off and return what remains of the dream to the backlog ready to be sliced further on another day.
• Don’t slice if you don’t have to, if it’s already the right size to fit within a Planning Interval then run with it. What is the right size? As a rough rule of thumb, a good size for a feature is roughly 2 weeks’ worth of effort for a team. That is an average, some will be bigger, some smaller, some will need multiple teams, following that logic through a team ends up with three or four Features per planning interval which should give them a good chance of getting them finished.
• Don’t slice Features up by component to distribute the pieces amongst the teams; by doing so you’re destroying the value, one team doing their piece doesn’t mean that the business need is fulfilled. Never invent work to keep teams busy, if there isn’t work for a team then they should use their free time to up-skill in an area where there is high demand. Remember we’re not optimising our system for utilisation, we’re optimising it for value, and by up-skilling they’ll be able to contribute to more value deliveries in the future. That up-skilling is also how you slowly change from complex sub-system orientated teams towards more stream orientated teams.
• Don’t forget Feature Testing, the slice has to contain all the testing to prove that it works as expected, including end-to-end, non-functional and other tests that won’t naturally arise as the sum of the unit tests from the stories.

In all of this the Definition-Of-Done is a handy reminder of everything that needs to be considered when evaluating and estimating the resultant slices.

Features are often sliced to create smaller units of value that can compete in the Weighted Shortest Job First (WSJF), some of the subtleties of WSJF are discussed in WSJF and Feature Slicing.

Conclusions

It’s about the knowledge and understanding behind those words and doing that preparation in a way that follows our principles and encourages those principles.

Releasable Value that meets customers Customer Needs and fits within a Product Strategy and has been elaborated through collaboration with all interested parties. Following Design Thinking’s double diamond, the Features are Problems for the Teams to Solve, not Solutions to enact, as this encourages the teams to start thinking for themselves.

Next

In PI Planning teams pull Features from the ART Backlog and create a set of stories to realise the value requested in the Feature. Some stories will go into the team’s own backlog, some stories will be negotiated into other teams’ backlogs.

So, the next webinar and blog will explore Writing better Stories.

---