One of the key activities that will help you make your Scaled Agile Framework program a success is the careful preparation of your Features prior to Program Increment (PI) planning. Also, one essential part of this preparation is to slice any of the focused-on Features that are too large to even think about being effectively delivered within the PI. In this Scaled Agile Program blog post, we might want to share some of our experiences in slicing Features.
FEATURES – THEY’RE JUST BIG STORIES AREN’T THEY?
It is very tempting for the Product Owners and Product Managers to treat Features as they are giant User Stories and to apply the approach of splitting to deal with the Features in their program backlog as they use the User Stories in their team backlogs. In the Scaled Agile Framework, a clear distinction is drawn between the purpose, structure, and content of Features, and that of Stories:
- Features are the visible ‘units’ of business advantage that the customer recognizes and it is at this level of Feature granularity that the customer will organize their needs.
- Multiple teams may work at the same time on a similar Feature. Teams can swarm together to deliver Features.
- Features can span multiple user roles, user stories, and use cases.
- Features may take many Sprints to finish. The Features are actualized Story-by-Story.
- Features should be effectively finished within a Program Increment; recall Features are to the longer 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 develop and deliver the Features. They exist to help the team analyze, examine, discuss and agree on the work they believe is needed to deliver a Feature.
- Stories can exist without Features, enabling the teams to make changes without the requirement for extra Features.
- Stories should be finished within a single two – week
Good Feature Slicing
Let us imagine that a team has recently valued a feature and has found that it’s too huge to easily fit inside a PI. To slice this feature, they should utilize a slicing strategy that gives them de-prioritize to organize or defer some of the less basic functionality. When the feature has been sliced, teams will implement the parts that deliver the larger part of customer value early.
What slicing strategies would be able to utilize? We have identified the following helpful examples for slicing:
- Keep it simple, stupid (KISS) Design Principle: Aim for the simple possible implementation of the feature that could be released without comprising non-functional requirements. This is regularly the cheerful way, with some fundamental error handling. Defer including the bells and whistles’, when the basics are set up and are giving a high quality, fit-for-purpose solution.
- Defer Optional Behaviour: Does the feature incorporate heaps of optional behavior? Consider making the optional behaviors 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 feature be released gradually to various zones of the business? Begin with the easiest business variation first to produce quick feedback. Maybe the feature can be launched in one geography, before including support for the others through additional features.
- Separate Different Channels: Could the feature be released gradually to help diverse channels, courses to market, or developments? For instance, unique working frameworks or the distinctive channels for retail banking, web, mobile application, and in-branch banking. It is logically a similar feature; however, the implementation for each channel could be sliced into an alternate feature.
- Address Different User Teams Individually: Do different teams of users need different types of functionality? The feature may speak to various demographics; each team might need to utilize the feature in a different way. For this situation, slicing the feature on only a subset of functionality for every demographic may appeal to the interest of the more important teams earlier.
- Consider Incrementally Sourcing Data: Is all of the information required before any advantage can be provided? Maybe the data can be consumed incrementally or sourced from existing secondary sources?
- Isolate Special Variations: First focus on the high volume cases then add more specialized corner cases as additional highlights. You may find that the value of the extra corner cases is low and should be implemented.
- Break out Common Enablers: Business features regularly depend on the equivalent underlying framework practices, impacting the implementation of the primary sets of features appear large and complex. Slicing them into business features and empowering influences can reduce the hazard and size of the features.
- Find a Story Group: Keep in mind the Pareto rule applies to features. 80% of the business advantage is probably going to come from 20% of the stories. Find these stories and treat them as their own feature.
- Break out a Spike: Often you don’t realize enough to plan a feature or to slice it into smaller pieces. In these cases, utilize an exploration enabler to look into what is required.
Bad Feature Slicing
It is important to understand the anti-patterns for slicing features and stay away from practices that put your solution in risk. Following are the anti-patterns when slicing or developing new features:
- Deferring Non-utilitarian Requirements: Avoid releasing features that have the core business functionality; however unacceptable quality and performance levels have. Work in quality, instead of depending on inspection to add quality later.
- Creating Feature Debt: There are circumstances, where limited releases of a feature to a subset of clients limit the number of applicable non-functional requirements. Extra consideration must be taken to guarantee that the feature isn’t therefore released to everybody, without including the missing functionality for the larger team.
- Slicing Too Early: Possibly slice a feature if it’s required sooner rather than later and it’s too enormous to move through the framework rapidly now. Keep in mind, estimates change after some time—what seems to be too huge today may have a lot smaller estimate later on as we learn.
- Over- Slicing: Avoid slicing a feature into smaller features all in one go. Generally, it’s smarter to locate the first or two key slices to be implemented and defer whatever remains of the functionality until input has been received on the initial slices.
- Slicing by operation or workflow step: It’s frequently enticing to slice a feature into a progression of satisfying ones to fulfill a progression of work process steps or activities. There is little or no business value in simply having the capacity to finish a single step. Rather, focus on identifying the core conduct and making the easiest end-to-end solution. Else, you may locate that 90% of the features are finished, yet users still can’t accomplish their business objective, nor complete the process they are attempting to perform.
- Slicing by Feature: We’ve found that technologists like to slice features by building segment, sub-framework or architectural layer. This is an unfortunate propensity and has similar issues to slicing features by operation or workflow step.
- Forgetting Feature-level Testing: Features regularly require extra testing past what’s expected to finish their Stories. Make sure to test each feature slice, just as the bigger solution purpose of the first feature. It’s simple for feature acceptance criteria to be lost in the wake of slicing a feature into smaller pieces.
For more blogs: https://blog.aleph-technologies.com/
Aleph Technologies is a premier IT training and staffing group with state of the art facilities based in Dallas, Texas. Aleph Technologies specializes in providing hands-on classroom based and onsite IT certification training courses taught by expert instructors with practical industry experience.