Non-software application of Scrum
Our team was selected by a government agency to develop a Digital Transformation Playbook to help SMEs embark on their digital transformation journey. Although the objectives were clearly outlined in the term of reference document, but the details such as what topics to include in the playbook, format of writing, content design were still unclear or yet to be confirmed. Due to the uncertainties, and the possibility of changing requirements during development, our team had decided to adopt the Scrum approach to work incrementally and iteratively to develop the playbook. Incremental and iterative development allowed us to deliver work items piece by piece realizing value with each delivery, and at the same time gather feedback from the stakeholders and make changes when needed.
During the project kick-off, the product owner was responsible to gather information, understand the client’s requirements and present a list of work items to the team. The list of work items was prioritized in order, with sufficient details for the development team to understand the work involved. The sum of all the work involved in this project is known as the Product Backlog in Scrum.
Figure 1: Example of Product Backlog
Collectively during the Sprint Planning, the team which consisted of the Product Owner, Scrum Master and the Developers (a group of designers and consultants) discussed those work items and selected the items with the highest priority to include in the Sprint Backlog. The Spring Backlog essentially is the list of work items from the product backlog that needs to be completed within a “Sprint” (a fixed length of event which work items are turned into value).
Figure 2: Product Backlog and Sprint Backlog
During the Sprint (1 week duration), the developers worked on completing the items in the sprint backlog. Every morning, the team gathered to discuss the progress of the work and obstacles (if any) in the meeting also known as Daily Scrum. At the end of each Sprint, during the Sprint Review the team demonstrated the completed work items to the stakeholders and gathered their feedback. The suggestions and feedback shared during the Sprint Review were taken into consideration to make adjustments or further improvements on the work items in the next sprints. This way of working was repeated in cycles (Sprint 2, Sprint 3….) with each new sprint taking in new work items from the product backlog to the sprint backlog, until the Digital Transformation Playbook was fully developed and delivered to the client.
Figure 3: Scrum in Action
By adopting the Scrum framework in developing the Digital Transformation Playbook, we were able to deliver a product that truly meets the requirements and needs of the client. This can only be achieved through early and frequent delivery of the work items, gathering feedback shared by the clients and make adjustments throughout the development process. Furthermore, from a commercial point of view, through frequent and consistent collaboration with the stakeholders, we were able to also build better business relationships with the client.
The above case study example provides a simple overview of how Scrum works, however there are still many other details about Scrum in terms of practices, techniques and theory that are not discussed in this article. If you wish to learn more feel free to contact us at firstname.lastname@example.org or drop us a message in the chatbox.