gap intelligence’s Product Development team practices Agile Scrum, which is a way to quickly develop and frequently deliver working software in small pieces at a time, in an iterative fashion. As a Product Owner of our agile scrum workflow, part of my responsibility is to translate stakeholder and customer requirements (what they want the team to build) into “user stories” that represent these rapidly delivered features. User stories are written in a way that communicates the desired software functionality to developers, while also keeping the user and business value in mind. They are meant to be independent, relatively small, and valuable on their own, but sometimes that is not the case initially.
Splitting User Stories
Any Product Owner working with user stories will face situations where the story is either too big, addressing too much functionality to be delivered in an agile fashion, or the feedback received on that story pushes the scope beyond its original intent. This is where story splitting comes in handy. By splitting stories, you can complete one piece of the puzzle that provides value on its own, while knowing that another complementary piece will be coming soon. The team can continue their progress, and you are free to re-prioritize what was not included in the original story against other features along the way. Although there are many ways to split a user story, here are three of my favorites covered by Scrum Alliance.
1. Simple/Complex
Focus on the simple core for the initial story and split off more flashy functionality for later stories. For example, a user wants to search for flights on a website. The initial story may be the ability to perform a very simple search between destinations, but future stories could include searching by airline, by date, by price point, etc., with each search feature potentially being its own independent story.
2. Interface Variations
Are their different ways to retrieve data on the user interface? Is there a simple way you could start with and write stories for a more complex interface later on? Perhaps to start, the user can search for flights by inputting the dates themselves in a drop down. A future story could be written to include a calendar date picker, and another story could be to include price points on each date shown in that calendar icon.
3. Deferring Performance
If you find the story is getting complex due to non-functional requirements, try delivering first on the core functionality and then addressing performance issues later. For example, if your story is about generating a file from a database, and during acceptance testing you receive feedback that file generation is taking too long, a later story can be written to generate the file in under 45 seconds. I find this splitting strategy is also quite useful for design or user experience feedback as well. Changing fonts, layouts, help texts etc. can all be deferred to future stories and re-prioritized against other features that make up the roadmap.
The more you are challenged to think about how to split up the work, the more you are exposed to the magic of agile scrum. Since the business landscape is constantly changing, stakeholder desires may also change quickly. As a Product Owner responsible for maximizing the business value of development work, the last thing you want is for the team to work really hard on something for a long time, only to find that certain parts are obsolete or that the project as a whole has been relegated in priority (and you have little to show for it). If you practice good story splitting, you should have independent and valuable working features, even if priorities change. To go even further, splitting stories can help turn that risk of business change into something that is welcomed and celebrated.
For more than 17 years, gap intelligence has served manufacturers and sellers by providing world-class services monitoring, reporting, and analyzing the 4Ps: prices, promotions, placements, and products. Email us at info@gapintelligence.com or call us at 619-574-1100 to learn more.
