Optimizing Software Delivery
User stories are linked in the wiki. When most ticketing systems are closed, they are archived. Omit user guides; they evolve. As a user, we need to specify the desired outcome for the story title. It’s a great way to start, but do we need to repeat “as a user” every time in the title? Instead, let’s use the feature’s title. For example, “Email Notification.” Before diving into the details, the story should elaborate on the feature in a few sentences. Extra information about the specific ticket can be added in the notes section. The user’s actions and details can be further elaborated upon, and including them in the wiki is recommended.
Now, let’s discuss what “done” means. When we say something is done, it doesn’t mean the coding is finished. Retrospectives are crucial during sprint intervals, whether two weeks or another duration. The first four or five retrospectives are exciting and productive if documented. For example, we can discuss what went well, what could be done better, improvements to be made, and personal grievances. It’s essential to communicate and not keep things secret. Action items should be noted, indicating what will be done to address any identified issues. These documented retrospectives can be shared with the manager. Fundamental problems may arise, and addressing them will help solve significant issues.
A user story always represents something of value to the business. It can be seen as a thin vertical slice cutting through the horizontal layers of the system. The business value can be quantified. User stories shift the focus from how the product will be built to how it will behave. They are independent of each other and can be implemented in any order. User stories should include only some implementation details. Instead, those details should be negotiable between the developers and the business. A user story should be manageable, allowing one or two developers to implement it within a single iteration.
An iteration should contain a similar number of stories as there are developers on the team. The progress of an iteration can be predicted based on the previous iteration. The main advantage of User Stories is that they ease sharing the user’s perspective of the system. Ideas can be debated and analyzed by defining the expected behavior in a shareable form. Refactoring, architecture, and code cleanup should not be treated as user stories.
Software delivery is an ongoing process of continuous improvement. A robust software delivery capability can provide a competitive advantage. Yet, teams and organizations often fall back on old habits, relying on outdated approaches with the mindset of “we’ve always done it this way.”
Customer collaboration is crucial for successful project delivery. We must work together to achieve our goals. Although it may seem romantic, it has proven effective. Being responsive to change is vital. We must adapt and ensure that documentation only precedes some things. Our focus should be on delivering working software while maintaining a steady rhythm. These principles are fundamental and deserve attention in our work.
