Practical examples to improve productivity in Scrum
One of the main reasons for failure in scrum-executed projects is accepting the correct product backlog items into the sprint. However, the problem is a lot more difficult to solve than it sounds. We have come to learn that it is important to determine what criteria should product backlog items (in our case user stories) have in order to be admitted into a Sprint. Everyone talks about Definition of Ready but no one sets down examples that can be put to use in real life, right away. Therefore, the aim of this article is to contribute with examples of a finished project with clear Definition of Ready and the use of Spikes that in our eyes and the eyes of our customer was an extremely successful implementation.
The following five suggestions should help your team clarify what needs to be done and put actions in order before starting each sprint. We have noticed several improvements in our company by taking these specific actions so as to have user stories accepted into sprints. Firstly, the Product Owner should clearly prioritize the items that are expected to be worked-on next. Each of these should include a clear description and acceptance criteria that is understood by the Development Team. Secondly, having adequate designs that correctly illustrate the requirement. If there are none, one risks being left open to the Development Team’s interpretation, which generally leads to misunderstandings and incorrect implementations. This is mostly important in cases with a complex interface to be developed: preexistent, available, and sufficient designs are a must. Thirdly, if the project requires integrating with an external provider or component, there is always the risk of arriving at the end of the process and encountering issues on the other side’s APIs with little time left. What should be done to mitigate this risk? The first thing that ought to be done in these cases is a Dummy Test to check the connection and its parameters. An analysis of this element and the impact on the product needs to be done prior to accepting the item into the Sprint. In order to do this, we create a Spike, a user story for which the team cannot estimate the effort needed yet and needs to further evaluate the issue. Doing this in advance will anticipate potential connectivity problems that should be corrected before investing hours of work on a dead ended task that will compromise the whole sprint. Even though, technically speaking, this technique is not 100% Scrum, it is a tool we proved useful to minimize Sprint carryovers (a user story not finalized, not accepted, and moved to the next Sprint) and negative impacts. Fourthly, even though the Product Owner is the final responsible for prioritizing an item into the sprint, they may have other stakeholder needs that may contribute to deciding whether including the product backlog into the Sprint or not. However, in order to make this decision the stakeholders that have requested the feature need to be in agreement regarding the description, acceptance criteria, and any other assets before it becomes a Sprint backlog item. Fifthly, it is of high importance to detect if functional dependencies exist before adding an item to the Sprint. For example: if a certain User Story can only exist if there is a preexistent one from which it depends, this dependency ought to be included first. If this is detected once the Sprint has started, there are many chances that the Sprint item will not be finished.
It should be noted that the Definition of Ready can be a double edged sword because if one is too meticulous when accepting items in the Sprint, one may end up accepting nothing or very little. This is why it is important to have the right amount of what should be done written down. Having too much can also have a negative impact because in that case, one would always be writing instead of doing and trying to have the perfect definition when the objective is to have functioning software that adds value to the business as soon as possible. Scrum ought to be used for uncertain contexts based on the three well known pillars: testing, validating, and evolving. Having everything extremely clear, as it may happen in Definitions of Ready, may be a mixed blessing: balance is key.
The recommended actions above have shown to bring positive consequences in our company. They improved our team’s performance by approximately 86%. They better the team’s trust in accepting user stories in the Sprint. In addition to this, they minimized the amount of carryovers in more than half the features in comparison with before implementing the improvement. They also determined the need for more detail or for developing User Story Slicing. Last but not least, they anticipated the problems before even starting the Sprint.
Regardless of working using scrum internally in your company or for a client, organizing the process has huge benefits for everyone. If your client or sponsor feels you are complicating a process that seems simple enough by formalizing this process, push to have a few test Sprints such as this. The results will be measurable quite quickly and prove your point right away.
We help clients grow their businesses by making creativity, flexibility, and talent converge into software development and UI/UX design. We are passionate and committed to take on challenges that can drive your business forward.
We combine our experience in Ecommerce, mobile, and web across various industries such as retail, wholesale, healthcare, government, and entertainment. This way, we work closely with you as a team in order to collaborate towards successful implementations.