Even in modernization work, user stories are needed. Modernization work is not just technical work that developers can manage themselves; it should be developed as any other new feature, with requirements and acceptance criteria. Architects, developers, and product managers should work together to clarify the work needed for the thin slice that may not be represented in the Boris diagram and break it down into user stories.
Stories are usually written by a product manager or product owner. While this is the expectation, architects often contribute as well by:
Oftentimes, new details and complexities arise when providing more context for the user story. This may trigger the architects to pair with developers to come up with a solution. Sometimes the complexities are outside of our control, for instance, if it is dependent on another team or because of a technical limitation. In these cases, an architect can be helpful by thinking through how the team can address the complexities in the short term while also building out a long-term solution.
💁 Tip: Make sure to update the Boris and SNAP diagrams when changes happen, including temporary and short-term solutions so that the team has an accurate representation of the decisions made.
During the process of writing stories, the architects should be involved to help identify critical pieces of information that are already known. For example, this could include the specific data tables that the new service will need to call. These details should be called out in the stories created when pairing with the product owner or product manager when writing the stories. Involving the architects saves the developers the time it would take to research the information and allows the architects to quickly disseminate patterns of the system to the team.
Developers contribute to the story writing process by providing implementation details that would help make the development process smoother. These details can range from small details that only certain individuals know to patterns that may help make the coding smoother.
Some examples of these implementation details can include:
In addition to implementation details, developers work with architects and product managers to clarify the requirements and acceptance criteria. They may ask questions such as:
Product owners or product managers should be writing stories that represent the notional architecture diagrammed in the Boris diagram and SNAP exercise. The Boris diagram shows the high-level relational architecture between different service candidates. The SNAP exercise should include more details on each of the service candidates, such as specific pieces of functionality, events to emit, and any external systems impacted.
The Boris diagram shows the different service candidates and how services relate to each other. Following the lines between the services, create a thin vertical slice of functionality that can be independently shipped to production. The SNAP exercise will include the functionality that the service will need. These functionalities will be the stories that have to be written.
📌 Example: A thin vertical slice story should cover the UI inputs that call a service, which in turn calls the database or data layer to retrieve the data and return to the user on the UI.
While writing stories, product managers may be asking themselves the following questions:
The first vertical slice is usually “fatter,” since developers will need to stand up the initial services and APIs. However, once this first story is completed, the rest of the stories that add other functionality using the same services and APIs will involve less complexity and effort.
💁 Tip: The first story in a vertical slice is a great opportunity to discuss with the team how they’d like to split the work into manageable chunks while still following the INVEST best practice for story writing!
While it might seem like writing user stories is a solo effort by the product owner or product manager, architects and developers both play important roles in making sure that the team, as a collective, is clear on what and how they will build the solution. Furthermore, the team establishes a shared understanding of the system as a whole and why decisions were made.
In the next lesson, we’ll look at collaboration amongst a balanced team while implementing the user stories.
Writing Agile User Stories for Event-Based Systems | VMware Labs Practices Site