In a previous article I have given an introduction to Scrum. There, we have seen some principles of this Agile framework, pretty much a taster of what it is. In this article we will take a closer look at what it looks like when put into practice through a case study. Ready ? Let’s scrum !
Picture the scenario: The Director of a Bank’s loans’ department is requesting to build an application that will act as a registry of the real estate properties in mortgage loans.
The application will have the following characteristics:
– It has to be online and accessible from the bank’s intranet
– Available only to specific individuals within the branches and the back office.
– It will have the following user interfaces:
- A screen of the mortgage loan contract including details of the property where users based on role can insert, update, delete or just view the details
- Capability to search based on keywords
- A Statistics screen
– There is also the requirement of migration of existing data in Excel before going production.
This project is extremely urgent because the Bank’s Audit department has requested to have as soon as possible a persistent repository of the data instead of the Excel because of the risks it carries on safety and data loss. And yes, there will be sanctions for the bank if not done immediately. To complicate matters further, the Director has warned that there may be some time until all the exact details of the requirements have been drafted.
The Development Manager decides that the best option is to run the project with Scrum so that work can start immediately with whatever initial specs are available and it is not affected by delays in the delivery full requirements. At the same time, they will be able to have after a first iteration of development a potentially shippable product that may satisfy the Auditors.
The Development Manager assigns the Scrum Master and the implementation team consisting of 4 core developers, 1 tester. The business Director assigns a Product Owner and also representatives of the end-users
Then the work begins as follows:
The Product Owner prepares the specifications and gives priorities to the various functions in the following order:
(1) Data insertion screen
(2) search page with basic filters
(3) Migration of existing data
(4) search page with advanced filters
(5) Data Statistics page
All these items and their particular specifications (user stories) form the Product Backlog which is continually reviewed and re-prioritized.
B) Iterative Development – Sprints
The Development team closely worked with the Product Owner to assess each item and estimate the effort required using various techniques (velocity, planning poker etc.). They also decided:
(a) How long each development iteration (Sprint) will be
(b) What is the definition of a “done” product i.e. that they would consider a completed and potentially shippable product
(b) How many items they can commit that will be “done” within each Sprint. These items will form the Sprint Backlog
– Sprint Planning
The Product Owner and the Development Team do a review of the Sprint Backlog and then the Development Team alone discuss the Sprint Backlog and breaks it down to tasks. In this particular project they decide to give the authority to the Scrum Master to ensure proper maintenance of the Sprint backlog, Sprint Burndown Chart and the Sprint Task Board.
Since the team has worked together on similar projects in the past and taking into account the effort required for each task (using velocity) plus their availability for the next period, they estimate that:
(a) the project will be broken down into 3 Sprints, each 10 working days long
(b) The corresponding Sprint Backlogs will contain the following user stories from the Product Backlog:
SPRINT 1: User Story (1) and (2)
SPRINT 2: User Story (2) (3) and (4)
SPRINT 3: User Story (5) and any leftovers from previous sprints
(c) Based on the expertise of the developers (2 seniors, 1 medium and 1 junior) it was decided to pair 1 senior and 1 junior (Pair Programming) throughout the course of the project. The tasks the pair would pick on the Task Board had the estimates doubled.
(d) It was decided to use a Fibonacci series to assign effort required to each task. Going through a Planning Poker process each task could be given any score in the 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 series.
(e) A product would be “done” only if all features were completed and all xUnit tests were passed (the team would have Continuous Integration with builds produced overnight and the they would have a Test-Driven Development approach, thus all features would have corresponding xUnit tests)
– Daily Stand-up meeting
Each member of the Development team states within 3 minutes maximum (15 minutes / 5 members = 3 minutes):
– Progress in the previous day
– The next steps
– Problems faced and what they need to resolve
The daily stand-up meetings always took place at 10am at the meeting room nearby and the Development Team authorized the Scrum Master to arrange for the booking of the room throughout this period.
In case of problems in this project, the Scrum Master has been authorized by the Development Team to facilitate their resolution. For example, in Sprint 2, it emerged that it was impossible, based on the specifications, to automate the migration of 200,000 properties in the database due to some corrupted data. Following identification of this data the Scrum Master reviewed this with the Product Owner and the latter decided that they can be excluded.
Due to the problem just mentioned, the user story (3) was projected that it would not be completed in Sprint 2. The Development Team negotiated with the Product Owner to deliver the User Story (3) in Sprint 3 which had some time set aside to fit the implementation of any left-overs.
– Sprint Review Meeting (max 2 hours)
Given that a monthly Sprint has a max of 4 hour Sprint Review, our half-month Sprint had proportionally less i.e. 2 hours. During the demo of Sprint 1 it was decided to not roll out the “done” increment but following the review of Sprint 2 the Product Owner decided to roll out the completed work to production as a pilot which the Auditors approved.
Furthermore, in demo 1 and 2, the users suggested changes, particularly in terms of the search filters and fields in the data insertion form, which were managed to be incorporated in the next Sprint.
– Sprint Retrospective (max 1.5 hours)
Given that a monthly Sprint has a max of 3 hour Sprint Retrospective, our half-month Sprint had proportionally less i.e. 1.5 hours. During the general discussion within the development team a number of points have been raised on how to improve the team efficiency. An example has been that in Sprint 1 retrospective, on of the developers mentioned that the specifications of the data insertion form could have been better worded to make it faster to implement them. The team authorised the Scrum Master to coordinated with the Product Owner to improve wording in the rest of the specifications.
In this article I attempted to give a taster of how Scrum can been applied in a real-case scenario. The benefits of this method in this case were:
- Even by the end of the first sprint, the business had a functional application in its hands with features requested by auditors (persistent data with secure access). In standard waterfall approaches, the first 10 days would have probably been spent in drafting and signing off very detailed functional requirements.
- The users have been perfecting the application after they saw the results during implementation instead of waiting to finish throughout and lost additional time at the end
- Even in the cases of delays (e.g. in the case of the data migration), through the daily stand-ups and the close involvement of the Product Owner plus the guidance and contribution of the Scrum Master, solutions can be found so that
I will not be tempted in this article to compare Scrum with Waterfall methodologies. I am planning to do this in an upcoming post. But, objectively speaking, it is a lightweight and yet robust framework, that needs few requirements to kick off and progress to the delivery of products unlike traditional methodologies with much less flexibility.