Within an agile context, a user story is a plain language description of a particular feature of the product or service to be created, written from the end user’s perspective. Well defined, prioritised user stories are the key to being able to explain the required functionality in a way that is easily understood by both technical and non-technical individuals. In essence, they provide the “What?” in order inform the “How?”. But where do you start? Who do you speak to? What inputs do you need? At Analyze we employ the following 3-step approach: Step 1: Documenting the as-is An important starting point before getting into solution mode is to take the time to understand your current processes and systems to get a detailed view of your problem areas. As an outcome of our as-is process analysis we create a top-down view of processes, including systems and roles, across the business value chain. This provides a better understanding of the systems and process linkages, inefficiencies, and opportunities for improvement. Step 2: Defining the to-be In this step we create the desired future state view of your process and systems landscape off the back of understanding your current problem areas. Part of this step also involves completing a gap analysis by comparing where you are today to where you’d like to be. This identifies the work needed to get there. To-be process maps not only provide a visual breakdown of the ideal future state, but also serves as a way of validating your business value chain. These to-be process maps can then be used as the base structure for defining your requirements. To-be process maps are further enriched with process “narratives” which cover your business rules, information around any regulatory or audit requirements, timing and sequencing considerations, and a view of all the systems involved. Step 3: Convert your to-be ideals into user stories When creating your user story structure or story map, the high-level processes from your to-be process map become your epics, while the process sub-tasks translate into your user stories. To-be process maps also allow you to identify user personas. Personas represent a type of user that will interact with your solution in a particular way and perform a defined set of tasks which allow you to group your user stories in a logical way. User stories typically need a couple of rounds of refinement to ensure that they’re not too big and that they have the right level of detail which should always include a view of its acceptance criteria as well. This iterative process should be a collaborative effort between the product/service owner, end user, analyst, and any applicable technical resources. If it’s not done in a collaborative way you will end up with a one-sided view that may not achieve all of your to-be ideals. The outcome We’ve seen how following this approach better equips our clients to move onto the next step, be it an RFP process or an internal build. It helps to better describe the complexity of the work, the type of skills and systems that will be required, and even how the work could be prioritised into an MVP. For the client it is easier to relate to the work to be done and for their vendors and suppliers it makes it easier to size and pitch on the solution, thereby creating an improved position for all. If you’d like to chat to us about helping your organisation build better user stories using a process approach, give us a call on 021 447 5696 or email us on info@analyze.co.za. Our team of skilled business analysist have experience across a wide variety of technologies, delivery approaches and industries, ensuring that we will help you improve your business.
