A crash course on Scrum part 2 - an agile project management methodology
Read the part 1 of this article here. Part 1 gave you an introduction to what scrum is, why use it and the various roles members of a scrum team play. The part 2 below gets more technical and elaborates on metrics and tools used in scrum for tracking progress and estimation.
Management tools and metrics in scrum
Scrum provides a set of tools, terms and metrics to organize and manage your project. Let us visit them briefly here:
Product backlog
The backlog contains the list of all requirements. Each item (a PBI - product backlog item) in the backlog is written as a user story. The PO (product owner) prioritizes the backlog and arranges the items in the order in which it has to be finished. The order of backlog should maximize the ROI.
User stories (PBIs)
Each PBI is written as a user story. User stories are of format:
As a <role>, I can <feature / function>, so that <goal / value>.
For example, the user story for backup camera in a car can be written as
As a driver, I can use the back up camera when I am reversing the car so I can see what's behind the car more clearly than what my rear view mirrors show.
Tasks
Each PBI written as a user story will have a set of clearly defined tasks which need to be finished to call that PBI done. The scrum master encourages the team to come up with a definition of done. This definition can vary slightly between each PBI. The purpose of this definition to establish and maintain the quality of the product being delivered over several sprints. Tasks are usually technical in nature and they are collectively created as a team during the scrum planning meeting.
Epics
When a bunch of user stories come together, they form an epic. Consider an epic as a large feature that is composed of many sub features that together make a functionality complete and usable. In the case of the backup camera user story we visited earlier, an epic would be a collection of few more user stories such as:
- Turn on back up camera when put the gear shifter in reverse
- Enhance back up camera feed with steering predictors / guides
- Alert with audio and steering wheel vibrators when a moving object is detected in the back up camera feed
- Alert lane departures using back up camera feed.
Each of these PBIs are of value both individually and collectively as an Epic. It is the product owner's responsibility to break down user / stakeholder requirements into such PBIs while ensuring they are not too big to be completed within a sprint. Over time POs gain this skill set. The nature of scrum encourages iterative delivery, thus the PO would boost the primary goal of a back up camera - visibility during reversing as the first PBI that gets done. All other PBIs would later be delivered during the subsequent sprint cycles. Should some catastrophic event or budget cuts happen during the development phase, the product (backup camera) is still usable after the first sprint as it satisfies its fundamental goal and the minimum shippable criteria.
Next, let us discuss about some metrics to quantify and estimate progress of a scrum team.
PBI estimates
Scrum believes in breaking down your product releases (or epics) into smaller identical building blocks called PBIs. No matter how hard you try, not all of your PBIs would be of identical nature in terms of complexity and effort. Further, some of your PBIs may be diagonally opposite that they may have nothing in common. Some of your PBIs may be so new to everyone in your team that nobody knows exactly how to finish it. Then how do you estimate the effort, provide a delivery date and bill the customer?
One way to estimate is to treat the PBIs as abstract entities and judge them relative to one another in terms of time or effort required to finish them. As a team, during the sprint planning meeting you arrange the PBIs in ascending order of effort involved. It is much easier to compare a PBI against another PBI which your team has completed in the past and evaluate comparatively if it requires the same, lesser or greater effort. Then you assign effort in abstract terms such as T shirt sizes (S, M, L, XL, XXL, ..) or Fibonacci number sequence (1, 2, 3, 5, 8, 13 ..).
Thus, in the backup camera example from earlier, a team may evaluate
- Turn on back up camera when put in reverse --> S or 2
- Enhance back up camera feed with steering predictors / guides --> M or 3
- Alert with audio and steering wheel vibrators when a moving object is detected in back up camera feed --> L or 5
- Alert lane departures using back up camera feed. --> M or 3
Time and effort estimation are much accurate as long as you work with smaller numbers (S, M or 1, 2, 3 ..) and they get fuzzy and uncertain once they go beyond 8 or XL size. If you find yourself with PBIs that are in larger end of effort spectrum, try to break it into smaller pieces. Since you write the PBIs as user stories, the PBI estimates are also called as story points.
Sprint velocity
Once you start to quantify your PBIs with story points, you can calculate how much you manage to finish during a sprint. Remember, a PBI is considered finished only after it meets the definition of done explained earlier in part 1. This number which is the sum of finished PBI story points is your sprint velocity.
In the backup camera example, if your team finishes the first two PBIs in a sprint, then your velocity is 2 + 3 = 5. If your sprint consisted of 3 weeks then you may understand that 3 weeks is the time required for finishing an effort 5.
Just like the story points, the velocity is highly subjective to each team. Two scrum teams cannot compare their velocities since it is arbitrary in nature. However, the velocity is a useful metric as it allows you to estimate how many PBIs can be completed in a typical sprint.
From the example above, if your sprint velocity is a 5, then you may estimate that you need a minimum of 2 more sprints to finish the remaining 5 and 3 story point PBIs. Once that epic is finished, the PO can call for a release cycle and release the full product.
The burn down chart
Now that you have enough metrics to play with, you can create a chart to visualize them. Simply plot the time (perhaps in the form of sprints) in X axis and PBI story points for an epic in the Y axis. Next plot your the velocity for each sprint as a line chart, you get yourself a burn down chart. The chart helps you to inspect the pace and estimate when the epic would get done. You can take precautionary measures if you anticipate requiring more time.
Using scrum to plan your projects
Now that you are familiar with the terminologies and tools involved, let us review how to apply them in project management. In the agile management approach, you plan for releases in three levels.
- First is the release plan. Here, the product owner arranges the PBIs and or epics in the order of importance or value. The PO takes a call on what to include and what to leave out. All the PBIs go into the product backlog list.
- Each release is composed of one or more sprints. A sprint is a short two to three week period where the entire scrum team comes together, works on one or two PBIs and finishes it. During the sprint planning meeting, the scrum master coaches the development team to work with the PO and pick the PBIs they want to finish during that sprint. These PBIs enter the sprint backlog.
- During the sprint, the team meets for a short 15 min stand-up meeting where each member states what they worked on that day, plan to work the next day and if they have anything impeding their progress. The scrum master takes responsibility to clear these impedences. The product owner clarifies any questions the team has.
At the end of the sprint, in a sprint review meeting the team demonstrates the finished product increment to the stake holders and get their sign off / agreement. This is also a chance for the stake holders to request for new features or modify the goal of the project based on changing market needs. If such a case arises, the product owner adds them to the product backlog. At no cost can the stake holders interfere a scrum team during a development cycle.
Also at the end of the sprint, the team convenes for a sprint retrospective to discuss how the iteration went, what can be improved or changed. The team either proceeds to or reconvenes to plan the next sprint in a sprint planning meeting. The cycle repeats with the team working with product owner to pick the PBIs they want to finish in that sprint cycle and so on.
Over this course, each team member have clearly defined roles and know what they are responsible for. The product owner continues to interface with the stake holders, get new requirements, keep the product backlog organized and prioritized by business value. The scrum master continues to perform the servant-leader role and coaches the team toward peak performance. The SM ensures the team is safe from external disturbances or injection of work items. The development team continues to make progress. They do this by taking as few PBIs as possible, work on them collectively as a team, finish and move on to the next. They ensure the finished PBIs meet the done specification before proceeding to work on a new PBI. If any task within a PBI is left undone, the team members feel free to grab it and work on it no matter what their speciality is. There is no ownership of duties, but there is ownership of the product as a whole.
Conclusion
Thus, scrum is one of the simple agile management practices. It may not be perfect and suit all your projects, but it definitely a good place to start if you want to build products and continue to remain agile and relevant.