Right-sizing features for SAFe Program increments
One of the key activities that will help make your SAFe® program a success is the cautious arrangement of your Features prior to Program Increment (PI) planning. Also, one essential part of this readiness is to slice up any of the focused-on Features that are too large to even think about being effectively delivered inside the PI. In this Scaled Agile Program blog post, we might want to share a portion of our encounters in slicing Features. What’s more, in tribute to Richard Lawrence and his well-known Story Splitting notice, furnish you with a complementary Feature Slicing notice for you to use in your SAFe program. (How nice are we?)
FEATURES – THEY’RE JUST BIG STORIES AREN’T THEY?
It is very tempting for Product Owners and Product Managers to treat Features just as they are giant User Stories, and to apply the splitting part way to deal with the Features in their program backlog as they as of now use for the User Stories in their team excesses. Similarly, as we have discovered that it can make issues compose Features utilizing the Story we have additionally thought that it was tricky to apply same splitting rules to Features from we do to User Stories. In the Scaled Agile Framework, a reasonable qualification is drawn between the reason, structure and substance of Features, and that of Stories (counting User Stories and Enabler Stories):
- Features are the obvious ‘units’ of business advantage that the customer recognises and it is at this level of Feature granularity that the customer will organize their needs.
- Features can traverse multiple user roles, user stories and use cases.
- Multiple teams may work at the same time on a similar Feature. teams can swarm together to deliver Features.
- Features may take many Sprints to finish. The Features are actualized Story-by-Story.
- Features should be effectively finished inside a Program Increment; recall Features are to the more Program Increments as Stories are to the Sprints.
- Stories are the units of work that each team breaks their Features into to help them gradually create and deliver the Features. They exist to encourage the team (and their partners) analyse, examine, concur and succession the work they accept is expected to deliver a Feature.
- Stories should be finished inside a single two – week Sprint.
- Stories can exist without Features, enabling the teams to make changes without the requirement for extra Features.
There are number of sources of rules for Story splitting, our top choices being those distributed by Richard Lawrence (counting his prevalent Story Splitting publication) and Dean Leffingwell. These standards still apply when utilizing Features and truly help groups in the identification, separation and sequencing of the stories they recognize to execute the Feature yet they are not as accommodating with regards to slicing up Features.
Good Feature Slicing
Along these lines, let us envision that a team has recently valued an element (ordinarily in story focuses) and has found that it’s too huge to easily fit inside a PI. To cut this element, they should utilize a slicing strategy that gives them de-a chance to organize or concede a portion of the less basic usefulness. When the component has been sliced, teams will actualize the parts that deliver the larger part of customer value early.
What slicing strategies would you be able to utilize? We have identified the following ten helpful examples for slicing:
Keep it simple, stupid Design Principle. Go for the least simple possible implementation of the element that could be discharged without trading off non-practical requirements, for example, frameworks execution, and so on. This is regularly the cheerful way, with some fundamental mistake taking care of. Defer including the bells and whistles’, when the basics are set up and are a giving a high quality, fit-for- purpose solution.
Defer Optional Behaviour – Does the element incorporate heaps of optional practices? Consider making the optional behaviours separate highlights to be implemented once the core usefulness is delivered and all the more learning has happened. You may find that these optional practices are not required.
Separate Business Variations. Can the element be discharged gradually to various zones of the business? Begin with the easiest business variation first to produce quick feedback. For instance, might we be able to do a straightforward answer for retail saving money before developing it for project managing an account, exchanging, and other keeping banking areas? Likewise, think about land varieties—in many projects the business rules vary by geography with various tenets for the US, Europe and Asia. Maybe the component can be launched in one geography, before including support for the others through additional features.
Separate Different Channels. Could the element be discharged gradually to help diverse channels, courses to market, or developments? For instance, unique working frameworks, or the distinctive channels for retail managing an account, web, portable application, and in-branch banking. It is coherently a similar feature, however, the implementation for each channel could be sliced into an alternate feature.
Address Different User Teams Individually – Do diverse teams of users need different types of usefulness? For instance, the component may speak to various demographics, in any case, each team might need to utilize the element in an unexpected way. For this situation, slicing the element on only a subset of usefulness for every demographic may appeal to the interest of the more important teams earlier.
Consider Incrementally Sourcing Data. Is every one of the information required before any advantage can be given? Maybe the data can be expended incrementally or sourced from existing auxiliary sources?
Isolate Special Variations. First spotlight on the famous/high volume cases at that point include the more specialized corner cases as additional highlights. You may find that the estimation of the extra corner cases is low and should be implemented.
Break Out Common Enablers. Business includes regularly depend on the equivalent hidden framework practices, influencing the execution of the primary arrangement of highlights to seem expansive and complex. Cutting them into business highlights and empowering influences can diminish the hazard and size of the highlights. Discover a Story Group. Keep in mind the Pareto rule applies to highlights. 80% of the business advantage is probably going to originate from 20% of the accounts. Discover these accounts and treat them as their own element. See Story Mapping for more data.
Break Out a Spike. Now and then you don’t realize enough to design an element, or to slice it into little pieces. In these cases, utilize an investigation empowering influence (for example a spike) to look into what is required.
Bad Feature Slicing
It is additionally imperative to understand the counter examples for slicing highlights and stay away from practices that put your answer in risk. For instance, know about the following enemies of examples when slicing or developing new features:
Deferring Non-utilitarian Requirements. Abstain from discharging highlights that have the core business usefulness, however have unsuitable quality and execution levels. We have seen many teams cause trouble by trading off on quality in their dash to get an ever-increasing number of features into the product. Work in quality, instead of depending on inspection to include quality later.
Creating Feature Debt. There are conditions, obviously, where a limited arrival of a component to a subset of clients limit the quantity of pertinent non-practical requirements. Extraordinary consideration must be taken to guarantee that the component isn’t therefore discharged to everybody, without including the missing usefulness for the bigger team.
Slicing Too Early. Possibly slice an element if it’s required sooner rather than later and it’s too enormous to move through the framework rapidly now. Keep in mind, gauges change after some time—what has all the earmarks of being too huge today, may have a lot smaller estimate later on as learning happens.
Over- Slicing. Abstain from cutting an element into loads of littler highlights across the board go. By and large, it’s smarter to locate the first or two key slices to be executed, and defer whatever remains of the usefulness until the point when input has been gotten on the underlying slice.
Slicing by activity or work process step. It’s frequently enticing to cut an element into a progression of satisfy ones to fulfil a progression of work process steps or activities. However, there is next to zero business value in simply having the capacity to finish a solitary develop. Rather, centre around recognizing the centre conduct and making the easiest start to finish arrangement. Else, you may locate that 90% of the highlights are finished, yet users still can’t accomplish their business objective, nor complete the process they are attempting to perform.
Slicing by Component. We’ve discovered that technologists like to slice highlights by building segment, sub-framework or compositional layer. This is an unfortunate propensity and has comparable issues to cutting highlights by activity or work process step.
Forgetting Feature-level Testing. Highlights regularly require extra testing past what’s expected to finish their Stories. Make sure to test each component slice, just as the bigger arrangement purpose of the first element. It’s simple for feature acceptance criteria to be lost in the wake of slicing a component into smaller pieces.
For more Blogs: https://blog.scrumstubs.com/
As a company comprised of individuals who have seen the vast number of improvements the Agile mindset can bring, It has become our resolute mission to bring Agile practices to every workplace the world over. We maintain to never become stagnant, to always learn more, to always improve ourselves, sprinting forward in a never-ending quest to make the world of work a better place. https://www.aleph-technologies.com/events