Scrum By Template

or “Patterns for Effective Scrum Leadership”

By Alfred Stappenbeck

For a better formatted presentation please see my google doc

Introduction

Who are you?

At the most abstract, I expect that the person reading this will be a software engineer. More specifically I expect the reader to have some responsibility organizing the efforts of a team of engineers. I’m not implying tens of engineers necessarily, in fact the context in which I developed these ideas were team sizes ranging from two (including myself) and seven (still including myself). I suspect that my suggestions will be useful to engineers responsible for organizing larger teams as well.

I’m also assuming you have some minimal level of familiarity with Scrum and Agile concepts. Maybe you have read Schwaber and Beedle’s “Agile Software Development with Scrum” or maybe you own it but never cracked it open. Maybe you have worked in a “Scrum” context for awhile and now find yourself in a position where you are expected or have desire to organise your team’s efforts.

I don’t expect you to be a certified “Scrum Master” and I don’t expect you to be passionate about Scrum. I do expect that you have enough interest in your teams results and are in a position to effect some change. throughout the course of this book I will make several recommendations and observations that I hope will be useful, but also expect the reader to apply their own context, taking what fits and leaving the rest.

My goal for you?

There are many flavors of unpredictability as your sprints unfold. I make no claim that I can address all those flavors. I do believe I have identified many common sources of unpredictability that can either be modestly controlled or at least used to raise your awareness and thereby put you and your team in the best possible position to know that you did the best you could preparing for and committing to a product owner. I do expect less stressful sprints, more time focused on meaningful work, more consistent work patterns that hopefully result in more consistent results. My highest goal for you is to provide a framework by which you can more effectively identify problems or benefits and act accordingly.

What do you want out of this?

For those interested in quickly putting a completely formed template into practice and uninterested in the back story or justification for why the template is the way it is; I offer a cookie cutter scrum template that has served me well for multiple years and multiple teams. For those who are more skeptical or just curious, I break down the template and explain each part, providing examples and justifications.

History of my template

My approach to scrum began after a rough start as a lead for a large online retailer. I knew little about agile except what I heard in passing conversation and brief explanations by people who probably shouldn’t have been attempting an explanation. There was no clear process other than a daily meeting. After leaving that company I joined a small media management company and soon found myself back in a lead role. This time review and planning meetings were required but the content of the meeting was entirely up to me. At this time my approach consisted of simply listening to complaints and trying to keep from hyperventilating. As lead /scrum master, people expected me to fix or rescue a tremendous breadth of issues. Before I could do anything I had to understand the issues all in a one hour meeting. One of the first challenges was retaining a multitude of issues that arose during the sprint. By the end of the sprint my mind was a blur and my emotions were high, commitments were often broken, product owners frustrated, dev managers looking to me for guidance. The initial problem I identified was that of memory. The human mind can only hold a limited number of concretes in focus at a time. Consider how you can look at collection of Lines ‘’|||” And easily identify that 3 lines are present without the need of counting. Now notice that “llllllllll” can’t be easily interpreted without engaging in a counting process which requires the use of memory. In the context of grasping what obliterated the commitments of a sprint, the easiest way to accomplish this is to journal throughout the sprint.

Sprint Journaling

The template that motivated this book started as nothing more than a journal, free of form. this initial journal contained brief explanations of events that prevented or inhibited the team from accomplishing committed stories. This simple journal was immensely helpful for the fact that it gave the recollections needed to put the closing sprint into proper focus. Often teammates had their memories jogged while reviewing the journal notes during review and more details would surface and provide important indications of problems and solutions. I recommend the journaling method for beginners. Focus on the surprises or mistakes during the course of the sprint. A good journal entry will be accompanied with a brief explanation of why the event had a negative affect and an approximate time required to deal with the surprise.

Who does the Journaling

I encourage everyone on the team to do their own journaling in addition to my own. In my own experience I quickly found that not everyone wants to do this. In most cases it was I the lead who did the journaling. This kind of activity is like doing dishes. Everyone knows it’s a good idea and if asked you can expect an agreement it ought to be done, but when it comes to doing it people tend to step back, not forward, that’s okay. As a lead it’s your job to be an example and demonstrate how things ought to be done. It’s your job to set the standard of productive activity. After all, your team looks to you for that.

Patterns Emerge

Over many sprints of keeping journals and reviewing them I found patterns emerging. The patterns formed the basis of the template. For instance, a common problem was a lack of understanding who was going to be in the office that sprint. Commonly I assumed that everyone on the team and all stakeholders would be present for the duration of the sprint. I eventually found that people had planned their vacations and failed to warn me. The commitments became impossible to fulfill. One week a senior developer would go on vacation, the next a product owner would be out and the senior developer would be dependent on information from the product owner. Had this scheduling conflict been made clear at the beginning it would have changed our committed plans. the additional benefit of having resource availability become an explicit planning activity, is that it shows the individual team members and stakeholders the impact their planning has on the team. This is not meant to discourage vacation, rather it seeks to encourage long range thinking.

Effective Journaling for Agile

Here is an example journal.

Monday

After sprint planning our product owner informed us that a new priority is going to take precedence and our committed stories are no longer relevant.

Tuesday

The evening lab maintenance took the team by surprise and prevented our nightly regression from submitting any test results.

Wednesday

A high priority bug for an important customer just came in and we didn’t plan for it.

Thursday

The senior dev on the team forgot to mention that he had a vacation planned for the middle of the sprint.

Friday

There was a planned company outing that we forgot to account for when we committed to stories.

Monday

We finally have a specification from the product owner and know he is on a plane to Florida for a conference. The specification doesn’t make any sense. Now we can’t start on the feature implementation.

Tuesday

Today we realized that we shouldn’t have committed to completing a test plan on a specification that we was finished in the same sprint.

Wednesday

While starting the test implementation for the new project we found significant technical debt. Many of the tests aren’t helpful.

Thursday

Pulled into a meeting for half the day.

Friday

Sprint review day is going to be rough, nothing is finished.

The argument for a templated approach

You may be thinking I’m crazy for proposing a patterned approach to something as flexible and uniquely implemented as scrum. After all it seems every company or team within a company; has their own way of implementing a scrum process. How could I possibly provide a template that could cover teams that have longer sprints, or different point estimates? The answer is that I’m not trying to offer a super detailed pattern. I’m offering an abstract pattern. I’m also suggesting that you may have to tailor the pattern to fit your team or company practices. The template I purpose is abstract. Let’s take a closer look.

“You can’t avoid …”

Beginning, Middle and End

All sprints have a beginning, middle and end. No matter how bad things get in your situation, there will always be these three phases. I’m not suggesting that the exact beginning, middle and end you committed to at the start of the sprint will transpire. I’m suggesting that regardless of what happens to your plan there will still be some kind of beginning, some kind of middle and some kind of end.

By itself I’ve stated the obvious and the totally useless. However, once you frame the activities that you do every sprint, sprint after sprint in this way you are primed to better see the deeper patterns that happen always or often within these three phases.

What generally happens in the “Beginning phase”?

Typically planning is undertaken in the very beginning. Followed shortly after by a researching or naive implementation phase which usually results in a surprise that leads the engineers back to product owners with fears about the likelihood of meeting the committed goals.

What generally happens in the “Middle phase”?

Depending on how long and involved the beginning phase was and how wrong your initial plan was, your middle phase will look something like a concerted effort to meet either the originally planned commitments or the newly generated commitments.

What generally happens in the “End phase”?

Depending on how the middle phase went you are probably scrambling to tie up work for stories, doing demos for your stakeholders and meeting to complete your sprint retrospective.

Beginning phase

The template starts chronologically with the activities needed to prepare for the beginning phase of the sprint. The overall goal you are working toward here is making a commitment that is based on something more than a hunch. I inductively identified the following categories that need your consideration before you can make a reasonable commitment. I don’t consider this an exhaustive list, simply the list that has helped me with most cases I’ve found myself in.

1. Capacity: Which is comprised of available time and team member availability. Account for holidays, team outings, vacations. All of these subtract from the standard total amount of time that work could be done on something.
2. Risk: Which is mostly about dependencies that your team will need that may not be available. Important customer milestones you may get disrupted with. Availability of product owners, program managers or stakeholders that you may need during the course of the sprint. Projects that may be nearing completion and cause disruption for your team. New customer engagements that could disrupt you. Changes to the product direction that have been brewing in the mind of the product managers.
3. Goals: The desired goals your stakeholders would ideally like to see finished
4. Velocity: Based partly on past experience with the team as it is currently structured. You need to have some idea how many story points your team can achieve acceptance on through the course of a sprint.

Once you have filled out each of these sections you are ready to make an estimation about how many story points you theoretically could complete in the sprint you are attempting to plan for. You can now start considering specific stories that relate to the goals you identified. You will find that not every goal can be accomplished. Stories should either have already been sized in a prior meeting or you have an efficient means of sizing stories during the planning meeting.

Middle Phase

During this phase your attention should be spent on leading the team and completing your individual contributions to the product or. Despite this focus, the template does serve a useful purpose as the place to keep your journal notes describing what went well or what didn’t. You may also keep track of takeaways here. You will present all of this at the sprint retro. Doing so will jog peoples memory and make the meeting go faster. If you are struggling with ideas about what to write about l provided a good example later.

End Phase

Congratulations for getting through another sprint. Your work isn’t over yet until you have extracted every once of value from the retrospective. Before i give an argument for a pattern I think it’s wise to explain my view on what I believe the retrospective should be, in abstract. I want to convince you that the goal should be constant improvement. I can recall being very confused when hearing talk like this. I had once interpreted it to mean that the velocity should just continue to increase forever. Needless to say I thought that was absurd. I can also recall coworkers joking about the same misunderstanding, not to mention a product owner who expected to see an ever rising velocity. This is not what I’m proposing. Constant improvement doesn’t necessarily translate into increased velocity. It is fair to ask what are we trying to improve if it isn’t going to show up in terms of improved velocity? The short answer is pride in the demonstrable output from your teams labor and thought.The thing we are trying to improve regardless of whether it reflects in points or not is your satisfaction with a job done well that you can look back on and honestly say the errors could not have been avoided. How ought this pride be achieved? To answer this we need to look at how sprints fail due to various kinds of mistakes and interruptions and how they succeed. You must observe your own attitude about whether you could expect yourself to have predicted an interruption or prevented a mistake. You must be willing to do this investigation and keep track of the observations and finally ask why? Why did this sprint fail while this other succeeded. Why should an explanation for a mistake be accepted versus another that should have been investigated deeper.Your answers need to be things you can improve on next time around.

The first step of this process is to take stock of which stories you succeeded accepting and which you did not. Take, care to find reasons for both the success and failure. Next, modify the goals section of the current sprints template. Make it clear to everyone in the room which goals were completed and which were not.

Blockers, errors and Interruptions

The purpose of these three categories is to help you identify the types of issues you encountered that may have reduced your velocity or made your experience difficult.

Blockers

I define this as some event directly related to a story that prevented the story from being accepted. For instance, let’s imagine a story that requires a new tax library be integrated with your product. You began the work and find that this new library has dependencies which conflict and no one is able to identify a fix in time. This would be a blocker.

Errors

I define this as an error a member or members of the team made. A great example of an error that I’ve made many times is under estimating the complexity of a story. Another example would be committing to a story that I was warned couldn’t be finished and failed to take off the list of possible stories for that sprint.

Interruptions

I define this as an event external to the team, that prevented the team from completing a story. A great example would be a high profile production issue or unexpected workstation failure.

As I differentiate the unaccepted stories into the categories, l prefer to explicitly verbalize and notate the stories that were impacted. This helps to make it clear to the team and stakeholders of the impact blockers, errors and interruptions have on a sprint. There is another reason for using the categories, they help you identify a course of action. An error made by a team member has a different remedy then an interruption. Errors may result in frank discussions with person or persons who caused the error with stress put on finding solutions that prevent the error from happening again. In the case of interruptions your attention and energy should be focused outside the team towards the source of the interruptions with the goal of either preventing them or similar ones in the future from impacting the team. Often the best you can hope for is simply to be made aware of the interruption before you commit to your sprint so that you may adjust accordingly. Alternatively you can take advantage of a willing manager, product owner or project manager to do this for you. In the case of blockers, often the only result is to keep working on the affected story. Sometimes new stories will result. For instance, extending the example of a failed attempt to integrate a new tax library, we may create new stories to address better organizing the dependencies. I typically avoid arguments about whether this is an error in estimation on the grounds that you often can’t predict a future purpose that will drive a requirement like how dependencies ought to be dealt with.

Takeaways

Throughout your classification it’s very helpful to keep a running list of concrete achievable tasks with names assigned, and to verbalize this list for the benefit of those in the review meeting.

Positives, Negatives and what you did

All of the classification performed up until now is getting you mentally and emotionally prepared for this last part. The first section we call out the actions or ideas that lead to accepted stories as well as a separate list of actions or ideas that prevented stories from being accepted. These two classifications are not meant to contain just anything positive or negative regardless what the source or effect. They very clearly are meant to describe actions or ideas contributed by the team members. The next section is more free form and is meant to be the emotional dumping ground to relieve some tension. Positives and Negatives are split out to prevent confusing the two. The only restriction i put on entries here relates to if they are better suited in another section. Frequently an item that was listed as an error will also be entered as something which prevented story acceptance. This is intentional. The purpose is partly repetition and partly to show that errors lead to lower acceptance. In my experience the repetition is helpful for the team and stakeholders, if for no other reason then not everyone in the room is always paying attention and if it caused lower acceptance it’s worth a little more attention.

Not just ticking off the boxes

To make the template effective you can’t just step line by line through the template and half heartedly put check marks next to each item. You need to be considering how each item in the template will require perception and thought throughout the course of the sprint.

Section 4 Beginning phase in depth

Estimation

The method for estimation i will cover of my own creation. You, no doubt will have your own ideas about estimation or can find more thorough coverage elsewhere. I provide my own mostly as an example to demonstrate an estimation method integrating with the templated approach to running an agile team.

Before we begin it’s important you understand the two fundamental considerations required to make an estimate. First, we care about capacity. Second, we care about the goals we want to achieve. These two are somewhat independent and somewhat dependent. Its’ difficult to know if a goal is reasonable without knowing what kind of capacity is available. I have found that treating them as independent tends to simplify things in the beginning. When I make an estimate I start with my resource capacity. I must know how many resource days I have available. A resource day is defined as one person available for one 8 hour day. I allow for half days but no less. I then sum up all resource days (and half days) from each person into a total. This total is not an estimate of points but merely a count of capacity to do work. This is a good time to switch to goals because your stakeholders will already have a sense of what is feasible when they see an initial idea of resource availability. For instance, it becomes clear that a key team member is out for half the sprint and that conflicts with a stakeholders availability. Initially,I ask for these goals in the pre-planning meeting and double check them in the planning day meeting. These goals are not stories but rather high level short statements, three to five words should do it. You may write down more goals then you can accomplish but they will get thinned out latter. Next establish a point system. I won’t pretend that mine is the best (I’ll describe later). With your point system chosen you can approach your creation of an estimate In one of two ways . First, tabula rasa or second, historical. lets talk the tabula rasa method first. I use this only when I’m starting a new team or the team has changed so dramatically that history is not useful. We need to get from resource hours to points. I do that with a ratio (points per resource day) or pts/rd. Without history we take a stab in the dark. For me I have found this ratio useful for just such stabbing (0.6pts/1rd or .60 pts/rd). What this implies is that 60% of the time your team spends working for the course of a sprint will translate into accepted story points. 40% either goes to unaccepted stories or is not accounted for. I then multiply my resource day value by my ratio and end up with points. This point value is our estimate of what we think we can commit to this sprint. Obviously if the whole team comes down with the flu then the estimate would be useless but we aren’t here to predict the unpredictable. Let’s discuss the other case where we have history. l accumulate history of achieved pts/rd by looking at past sprints accepted story point counts compared to the resource days. I do this as part of sprint retro I keep track of the three highest pts/rd ratios and the previous sprints. I then consider what kinds of risks or dependencies I have for the current sprint and make a best guess. If there appears to be nothing special about the sprint i will take the middle highest, if the stories are wrote familiar work I may take the highest. In some cases I may use discretion and reduce my value below the lowest. When the team changes I throw out my historical averages and begin from the tabula rasa position and develop history from there.

Point Systems

I have no intention of convincing you that I have the best point system. I have accepted a particular point system which has served me well and I’d like to explain it; for the purpose of having a complete story to tell rather than convincing you that one is better than another. There are better books to read on the subject of point systems in general.

l will start by explaining the features I care about and then I will explain the system. Fundamentally we need some way to describe the level of effort required to accomplish something. We need this not because we care about describing work more completely but instead to allow comparison to alternative solutions or to different endeavors. Secondarily, we can use an effort value to estimate expected delivery time if we can translate effort, resources and some effort to time ratio. I claim that the desire to estimate time to completion of some work is still a derivative of the root goal of comparison. After all an estimate of time completion is based on past experience, which assumes comparison to similar work. So first we need a mechanism for expressing effort. What better mechanism then numbers? We also want simplicity. We want simplicity in our point system because we have limited time and a system that is overly flexible will allow for unhelpful disagreement. These considerations lead me to accept the geometric point system limited to the values [l,2,4,8]. The purpose of limiting to four numbers is simplicity. The fewer options yon have to disagree over the faster it is to converge on a number. While practicing with this system I found that 8 served as warning and should never be used on a story that you were intending to commit to in one sprint. The result was always a split story that couldn’t get accepted. So effectively you could simplify to [I, 2, 4]. An additional and optional modification is the use of zero. This came to represent the estimated level of effort for something that could be completed very quickly but needed to be tracked along with the other stories. The other purpose it served was to track the occasional work of a person who was not on the team but who may have had work which couldn’t be tracked more effectively elsewhere and who’s point value you didn’t want influencing your sum of accepted story points.

Defining a point

Now that we have a point system we should make it clear what a single point is. I define it as the smallest unit of work effort we can account for that requires no more than a day to complete for one person. The implication then is that a two point story is twice the effort and four is twice that. In my experience it is helpful to treat a four point estimate as a full week. There exists a debate about whether one should tie a point value to time. I’d rather not get into that debate, although I am sympathetic to the side suggesting that it be divorced from time. If you are interested please see more robust sources on that specific topic. Mike Cohn has a good treatment in his book “Agile Estimation and Planning”. I believe that the point system I provide should work with either approach provided you account for time at some point in the estimation process that is clear to the stakeholders and team.

Example Sprint Planning Template

Resource planning

Person Resource days

Historical Velocity ( Top 3, by Pts/rd)

Sprint Risks

These things have changed (Customers, Products, Projects)

1. Customer Xyz is launching first Wednesday of the sprint, expect higher email engagements.

These things are similar

1. Still have vague specifications
2. Still waiting on virtual machine build from Ops

Will we have key stakeholders all sprint?

1. Product owner on vacation first week.
2. Dev manager traveling to Honduras in the second week.

Current sprint Point projection

Goal Plan

Deployments this sprint

1. US Eastern needs 1.0.3 before 2nd Monday
2. EU West needs 1.0.2 before Friday

Deployment Requirements

1. Purchasing version 2.0.1 must successfully deploy in US

Process improvements

1. Sprint planning will include a review of the our software licensing plan.
2. We should keep track of which customers have which early release builds.
3. Be skeptical of Critical/Blocker Escalations ( always go to PM and Support for confirmation of issue).
4. Ensure that we can reproduce our test environment by preserving the xsl files in \\testtw01.qa.testlab.com\e$\R2_software\XSL

Retrospective

Blockers

1. nightly regression failures prevented story 6 from being accepted. Issue related to lab maintenance.

Errors we made

1. We should have planned for lab maintenance since an email was sent out prior to sprint planning.

Interruptions

1. Customer XYZ needed unplanned, involved engagement

What did we do that helped us attain our goals and accept stories.

1. We sized our stories well despite blockers
2. Steven helped Jessie with Maven dependency issues

What did we do that hurt us in attaining our goals or accepting stories.

1. Failed to be proactive with the

Positives

Negatives

Takeaways

Best Practices Followed

• Test First Development on
• Sorting feature
• Bug Review
• happened twice this sprint

Section 5

Improvements to the template

The template example I have provided came with the expectation that it was all a place to start from and not a final destination. The point was not to follow a script from here on out without concern for constant improvement. Rather, I intended my recommendations to help you identify new problems and fit your new solutions into a general framework. Here are a few suggestions that helped me and I fit them into my framework.

Pre-planning

The idea that a planning meeting requires a meeting has often been accompanied by laughter since it seems to imply a never ending sequence of preparation for something which itself is intended to be a type of preparation. Let me present a justification for why this single meeting is valuable. I’m proposing that prior to your sprint planning meeting you get your team and stakeholders together and theorize or guess what your plan will look like for the upcoming sprint. I have heard this meeting given different names but I prefer to refer to it plainly as the pre-planning meeting. There are a set of considerations i have found, that have formed a repeatable pattern. In many ways these items mimic elements of the planning template and are intended to be transferable directly to the planning template. Let’s look these items in detail.

The first item to discuss is who will be available the following sprint or when will they be available. This advance discussion gives those less prepared team members an opportunity to think about the question before they come to planning meeting the following week. It also gives the organizer a picture of what may be possible. The benefit here is obvious, how can we expected to plan for commitments if we are missing the people we need to deliver those commitments. Beyond setting the expectations there are easily overlooked benefits like you find that holidays or special circumstances require you to schedule your sprint planning or retro on different days than normal.You can also identify which stakeholders will be available, this prevents overly ambitious commitments where presence of key idea makers is limited.

Next we look at what is desired to be worked on. These desires could be coming from outside the team or inside and what follows is the back and forth negotiation of priorities. Claims are made and challenged. Customer “wants” and product stability may be popular topics. It’s likely that some concrete stories will come directly out of this discussion. Often some follow up discussion or research needs to be engaged in before actual planning meeting. The purpose of this pre-planning meeting has been satisfied if it prevents an uninformed later planning meeting. I’ve been asked in seriousness whether there should be another meeting to help prepare for this one. Use your best judgement. As someone in a leadership or planning role you should have an eye towards next sprint and beyond as a constant background theme as you complete your days of the current sprint. Mid-sprint You may find it useful to start impromptu conversations relating to future initiatives and have your own mental picture of the current sprint and how the next may shape up.

Another useful section of the meeting is a review of past concerns that may have been deprioritized or concerns raised about the current progress through a project. For instance, we discuss technical debt, external expectations on other products or teams and expectations on deliverables. I like to keep track of concerns in an online document the team can reference later and see during the meeting.

Finally we look at a list of things required to be investigated or followed up on prior to the beginning of the actual planning meeting. I attach names to action items incase it isn’t clear.

After the template is a normality.

This topic is the most challenging to present because it is the phase that I’m currently exploring and have yet to settle on a confident conclusion. By this point you have built a template of your own or followed something similar to the one I created and you have conducted multiple sprints with it. I can’t claim to know how your team will function or how you will judge the results. I can’t claim that you will enjoy my approach to organizing a sprint. I would like to share my own observations.

As the template evolved I found my sprints becoming less chaotic and velocity more predictable. I also found myself feeling a little bored. Strange right? Shouldn’t I be so pleased and calm now that my sprints are far more ordinary? It turns out that some of the fun seems to be related to the unexpected and even the high tension moments that came with a looser team organisation. As my sprints became more routine I found that I could easily predict the general kind of experience the team was going to have next sprint and the sprint after that and so on. The template does become a kind of almost automatic pattern you can follow sprint in and sprint out without a whole lot of thought. I began to notice that it became easy to “phone it in” so to speak by simply following the template and doing the work. This is obviously not the end goal of my templating, to bore the pants off you and make your job dull. So where do I go from here? Where should you go if you have chosen to take my suggestions?

The template explained … [stay tuned for more later]

Originally published at docs.google.com.