Notes taken for posterity during the second of two days of a Certified ScrumMaster Training course that some of my colleagues and I attended this week. These notes are only intended to call out some areas that I found of particular interest during training, and are not intended in any way to summarize the course, which covers material far beyond what is outlined here.
- Release planning was pulled out of the July 2011 Scrum Guide, which returns Scrum to its original definition, but the Scrum Alliance will continue to include.
- Definite delivery dates, cost, and scope are not included in Scrum release planning. Release planning is not the purpose of Scrum. The purpose of Scrum is to be transparent and to determine what is available when.
- Scrum and Extreme Programming (XP) arose from the Patterns movement, because each of these is based on natural practices. Patterns are discovered, not invented.
- A release plan really just indicates which Sprints involve a shipment.
- Estimating is really design, because the clock is not brought into the equation. The conversation becomes more comfortable because the subject matter is more familiar and the entire development team is involved.
- Sometimes "ideal days" are used instead of story points, but for some this brings time back into the equation, which is not the objective. According to the instructor, ideal days in general tends to work.
- Larger tasks tend to be underestimated. The instructor advised not assigning numbers when an estimate is too much of an unknown, because estimates will be thrown off. This forces stakeholders to be aware that these larger tasks need to be broken down in the future. It is the stakeholder's call whether to spend time on one or more Sprints assigning estimates to these larger tasks.
- If there are many small tasks, it is permissible to bundle them as long as it makes sense to do so. In other words, the tasks are related and can be completed within a Sprint.
- Planning Poker sets are typically based on Fibonacci, so the instructor tends to suggest this sequence.
During the discussion, I had mentioned Powers of 2 as being popular, but the instructor tends to think that the numbers in this sequence increase too quickly. In speaking with some colleagues, we agreed that Fibonacci and Powers of 2 are similar if capped at say 16, and I later distributed a presentation I delivered a couple years ago that included several slides on how Powers of 2 were used for story points and how spikes were used on my project to assign story points to the building of proof of concepts with unfamiliar technologies that were planned to be used on the project. But since it is not always reasonable to cap at a certain number in the sequence, in retrospect I will be considering other sequences such as Fibonacci in the future, especially since we enjoyed using a traditional card deck to play Planning Poker (Ace = 1, 2, 3, 5, 8, Jack = 13, Queen = 21, King = 34).
During an exercise where the class broke down into 2 teams, we used Fibonacci to estimate tasks associated with kitchen remodeling.
The points that my team assigned to each of the tasks are listed on the left. Points are relative, and we did not see any tasks as being far removed from the others in terms of points. However, we did not end up assigning any points to the last task listed, because of the disagreement that ensued regarding the work to be completed. This task is an example of where a portion of a Sprint might be assigned to additional estimating.
The other team viewed the first two tasks as being relatively far removed from the others in terms of points, and in this case it is understandable how Powers of 2 might not be appropriate. As discussed by the teams following this exercise, the points assigned are either a reflection of unfamiliarity of this type of work, or the relative difference in skills between the individuals on each of the 2 teams.
- This type of estimation is really qualitative, not quantitative. Affinity Estimation enables quantitative estimation and is the fastest way to estimate a product backlog. The rule is that if a story estimate changes 3 times, it is set aside. Not only is time removed, size is removed. Affinity estimation is relative. The Fibonacci series is then applied afterward. The team quickly develops collective intuition.
- XP introduced the "courage value", which takes the lower number, rather than a conservative higher number, in the case that a team does not reach a concensus.
- During a class exercise that involved measuring velocity, the instructor pointed out that the team that is participating needs to be involved in estimating. Those not involved are not qualified to interpret past velocity activity.
- Use of Scrum is always forward looking by evaluating the past. What the instructor refers to as "Point Accounting" comes into play as tasks are not completed and work needs to be forwarded to the next Sprint. One strategy is to figure out how to complete a subset of the task in the first Sprint, and then forward the remainder. Another strategy is to move the entire task to the next Sprint and then count the points for the whole task. The instructor does not necessarily like this latter method, but for a services company like ours it might make sense.
- The Sprint is the only timeboxed item that cannot be changed.
- Part 2 of Sprint planning is where the bulk of planning occurs. The first part of planning tends to go quickly because much of the work is performed in the prior Sprint.
- Velocity should be used to determine what the development team thinks it can complete in a Sprint, not what it needs to complete in a Sprint based on expectations.
- It is rare that developers will sign up for risky tasks.
- Be careful about assessing importance based on the task name in itself, because for example the task might be associated with strategic work that is trying to set the stage for future Sprints.
- The Burndown Chart tracks how many hours remain, not how many hours have been applied to tasks. Keeping track of how many hours have been worked can be separately maintained elsewhere.
- The "truck number" is sometimes used to communicate how many people need to be run over for a particular skillset to be lost. A truck number of 1 is obviously never desired.
- It is a good idea to reserve a portion of points in each Sprint for support activities.
- It also sometimes makes sense for the experts on the team to be assigned no points in order to raise the skillsets for the rest of the team.
- Kanban is really an evolution of Scrum where work needs to fit into more traditional phases.
- It is not the purpose of the daily Scrum to report to the ScrumMaster. The purpose of the daily Scrum is for individual developers to share status with the rest of the team.
Interestingly enough, the role of the ScrumMaster in the daily Scrum was one of the topics that lingered during hallway chats while back at our client the next day. In our experience, it is common that ScrumMasters will address the rest of the development team one at a time during the daily Scrum, reminiscent of status reports to a project manager, but this should be taken care of prior to the meeting itself so that developers can share with each other. In my opinion, reverting back to the traditional status report format with which many are familiar is common when trying to create a Scrum hybrid that blends Scrum with current state client project methodologies, but should be relatively easy to steer away from when there is common understanding across the development team as to the purpose of the daily Scrum.
- The Burndown Chart should not be updated during the daily Scrum. The team should update before the meeting so that it does not lose its purpose.
- There should be a common vision coming out of Sprint planning that the team has a shared commitment. The purpose of the daily Scrum is not to focus on your own work as an individual.
Another topic that was discussed periodically the next day was the Ball Point Game exercise in which all attendees participated as one big team. For this exercise, we were to pass tennis balls to each other in a way where everyone touched each ball before it was placed in the bucket. But there were stipulations which stated that air time was required between each person, that balls could not be passed to direct neighbors, and that the person that passed the ball first also must be the person that touches the ball last.
And it so happened that I was the individual that was the one that passed the ball first and touched the ball last. By the nature of this position, I was also the one that kept count of how many times balls entered the bucket. Very challenging. Everyone remarked the next day how I was the one with the hardest task. Much like the ScrumMaster. Two of the many take-aways were that we found rhythm as at team after the first few Sprints, and that time spent on Agile Retrospectives is very small compared to the rest of each Sprint.
The exercise ran for 10 Sprints. During the first 3 Sprints, our velocity increased. Following the first 3 Sprints, I suggested we create a new formation and so velocity decreased while we were finding our rhythm again. Other suggestions on formation ensued, and velocity rose again until we found a more optimal formation in which velocity continued to accelerate. It is probable that had we run the exercise for additional Sprints we would have continued to increase velocity prior to reaching our limit.