Feeds:
Posts
Comments

Archive for March, 2012

Over the weeks we have had considerable deep dives into Scrum and how it has evolved over the last ten years. The first week we looked it at a high level, then we had a look at the roles, ceremonies and artifacts.

Now we have the opportunity to see how it has not evolved. It is important to note that Scrum is a Project Management Method (purists might argue it is a framework). It is not, nor has it ever said it was a methodology. Nor has never said it was a method for improving the capabilities of software developers.

It was created and in use prior to the name “Agile” ever being associated with it. It was one of the many “light-weight” methods that were contending for attention away from Waterfall. When Jeff Sutherland, Ken Schwaber and Mike Beedle joined fourteen other signatories in Salt Lake City there was little that they could agree with other than the manifesto. Despite this, the manifesto propelled the light-weight methods into the limelight and was a vocal enabler for a new future.

Some IT people have never experienced Waterfall or even RUP. They don’t know what it was like in the old days. Maybe the problems were due to commercial issues rather than method issues, but even with all the hoopla over Agile or Scrum not working or dead I remember what it was like in those days and we are certainly better off for those signatories creating the manifesto and propelling our focus.

But like Waterfall not being a comprehensive methodology Scrum certainly is not. This means that when people are trying to apply Scrum they are only applying a single piece of the puzzle. Many believe that Scrum = Agile. Those that know better are left in a minefield of information overload having to gleam which other methods they need to apply and how it will correlate with their existing process. In essence, Agile is like a toolbox. There are many tools that you need to use to fix the problems you have. Some tools won’t be the right tools for your problem. Arguably if you have no problems then don’t use any tools… as long as you aren’t fighting Ostrich syndrome.

Scrum has just a few of these tools. Over the last ten years it is evolved minutely to the problems and the new tools that are required in our box. Evolution did include the addition of retrospectives, intellectual property that was owned elsewhere. Even the origin of Daily Stand-ups was IP from elsewhere. Nothing is new, concepts are just re-played and re-packaged. Some might argue that the reason Scrum did not evolve was primarily due to IP concerns. But maybe, if the upper echalon of Scrum had listened to the voices of the community they would have had the opportunity to incorporate these new ideas and thoughts.

So what has evolved in the Agile community over the last ten years that Scrum has ignored:

  • How to apply Scrum to teams that have multiple customers that additionally have to support (ie potentially hotfix) production environments
  • How to identify constraints in the flow of the system
  • How to ensure that the work the Product Owner comes up with is the right work
  • How to incorporate feedback loops in order to verify benefits realisation
  • Stories, Epics, MMFs, MVPs, Themes, Parking Lots/Feature Progress Charts, BDD
  • How to estimate (eg planning poker)
  • How to understand what is more important – scope, cost, time or quality? eg Rob Thomsett’s Success Sliders
  • How to create a backlog in the first place
  • Who has the money and what visibility should they have?
  • Mastery practices, arguably owned by XP, eg pair programming, TDD, Continuous Integration; or even simply where design and architecture fits in
  • Where management, leaders, Project Managers and Business Analysts fit in
  • Where business cases, governance, procurement and commercial reality fits in
  • What tools to use to support the cultural change that goes along with implementing Scrum
  • How to create effective walls and other visualisation techniques
  • How to deal with the distribution problem (this is huge and only going to get worse)
  • How to apply it to anything other than software development
  • How to scale it to large organisations where team members are working on multiple projects at once or significant dependencies exist
  • How to get any form of metrics on effectiveness of the change including temperature checks of people’s comfort levels of the change
  • Incorporating all elements of the project and not just thinking of software development only – ie communications, training, process re-engineering

Maybe I am just asking too much. Methodologies seem to be dead, disparate ideas spread everywhere seem to be the norm. If complex systems are so hard why are we making it harder as a community to find the answers?

Read Full Post »

In Part 1 of Scrum evolution over time we looked at the high level overview of Scrum and how it has changed over the years. In part 2 we looked at the roles and part 3 we looked at the ceremonies and how they have adapted, or not, over the years. It is now time to have a look at the key artifacts. 

There are three artifacts in Scrum: Product Backlog, Sprint Backlog and the Burn Down Chart.

Product Backlog

The original June 2003 site did not differentiate between the Product and Sprint Backlog:

A prioritized list of all work to be completed prior to releasing a product :

  • Only one person maintains and prioritizes the backlog list.
  • Any interested party can request that backlog be put on the list.

Between sprints, all involved parties and the engineering team meet to determine which work can be completed in the next sprint, and what the executable will be.

In the 2007 pdf we have the Product Backlog defined as:

The requirements for the product being developed by the project(s) are listed in the Product Backlog. The Product Owner is responsible for the Product Backlog, its contents, its availability, and its prioritization. The Product Backlog is never complete, and the Product Backlog in the project plan only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used emerge. The Product Backlog is dynamic, in that management constantly changes it to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, the Product Backlog also exists. An example of a Product Backlog maintained on the Scrum Product Management tool, based in a spreadsheet.

In both March 2007 and March 2009 the Product Backlog definition was:

At the beginning of the project, the product owner prepares a list of customer requirements prioritized by business value. This list is the Product Backlog, a single list of features prioritized by value delivered to the customer. The Scrum Team contributes to the product backlog by estimating the cost of developing features.

The Product Backlog should include all features visible to the customer, as well as the technical requirements needed to build the product. The highest priority items in the Product Backlog need to be broken down into small enough chunks to be estimable and testable. About ten developer-days of work is a good size for a Product Backlog item that can be ready for implementation in the next iteration. Features that will be implemented further out in time can be less detailed.

In September 2010:

The Product Backlog is a prioritized list of everything that might be needed in the product. 

Within scrum.org the definition is now:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, and estimate.

The Product Backlog is often ordered by value, risk, priority, and necessity. Top-ordered Product Backlog items drive immediate development activities. The higher the order, the more a Product Backlog item has been considered, and the more consensus exists regarding it and its value.

Higher ordered Product Backlog items are clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are fine-grained, having been decomposed so that any one item can be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “ready” or “actionable” for selection in a Sprint Planning Meeting.

As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items is then employed.

Product Backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog grooming, items are reviewed and revised. However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform grooming itself. How and when grooming is done is decided by the Scrum Team. Grooming usually consumes no more than 10% of the capacity of the Development Team. 

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping understand and select trade-offs, but the people who will perform the work make the final estimate.

The ScrumAlliance definition of the moment is:

A prioritized list of desired project outcomes/features.

A product backlog is dynamic—Items may be deleted or added at any time during the project. It is prioritized—Items with the highest priority are completed first. It is progressively refined—Lower priority items are intentionally coarse-grained.

 Product Backlog results and opinion

  • My biggest problem with Scrum (other than it’s odd names for things) is that it creates this belief that this backlog of requirements just pops into magical existence with no work. This is not an activity that a Product Owner can do in a few hours. Nor is it something they should do alone. The whole team should be part of this activity to create the backlog in the first place. This is an opportunity for the team to be given context as to why this project came into existence in the first part, the opportunity to say we need to have a team or 6 or a team of 3 to get through the work in time against expectations. There is no recognition in Scrum of marketplace realities – projects are almost always constrained by either scope, time or cost. Vendors do need to still give some form of estimate of the end to end work – yes with knowledge that change will without a doubt occur, but the financial reality of this world is that software development work is capitalised by accountants and consequently needs to have funding set aside for it in advance. To do this the whole team needs to have a somewhat good understanding about the features and about the market pressures. I used to call this activity “Iteration Business Planning” and it would precede the start of iterations. An outcome of it would be a business case for the work to be done.
    Now before you start replying that this smells like waterfall I would say that it is a compromise. In waterfall such an activity would have taken months – what I am suggesting is that for a six month project this takes one week. It’s not big design upfront, it is the right amount of design and elaboration to ensure that you are building the right thing and that the right thing can be built to commercial expectations.
  • Thankfully over time the creator of the requirements was changed to not just be the customer or “Product owner” but that also the team could identify requirements. This hints at there being IT only features. The thing to be wary about IT only features is that they provide no value to the Product Owner, hence why are you doing them? If you can express in what way they provide value to the Product Owner (which you should) then they are really Product Owner features. Work such as “setup the database” is not a feature – you are doing that to realise some value in a real Product Owner feature.
  • All instances above take the line that prioritisation is only done by value. I would argue along with other Agile proponents (eg Alistair Cockburn and Jeff De Luca) that prioritisation should be done with respect to value and risk. This doesn’t mean that you do all the high risk features first. You do the high risk, high value features first. You do the high risk, low value features near the end (or never). It would be nice if Scrum was updated to provide further guidance on this.
  • The question of how often to Product Backlog groom (prioritise, estimate and discover) is an interesting one. Scrum.org says to do it as needed with this activity taking up to 10% of the Development team’s time in interruptions. I agree with the ‘do it as often as needed’ philosophy but be careful about how you implement this. It is important not to make the developers context switch too much and constant interruptions by the Product Owner of “hey, can you estimate this new feature for me?” is not the intent of this activity. Ensure that as a team you have worked out a strategy to minimize context switching but still enabling this to be an activity that doesn’t get skipped.
  • The fact that the Product Backlog will evolve over time is an important one. What I do get concerned about here is the commercial reality behind it. A certain amount of tolerance can probably be handled but how much are Product Backlogs changing out there? I really would love to see all of the Release Burn Charts across the industry to see where the scope was when the project started versus where it ended up being. Should we as a community not be gathering this information and asking questions about why it is shifting so much and whether there is a better way to predict such dramatic shifts in the future?
  • In the March 2007 data capture, the ideal size of a feature was defined as 10 days. Scrum.org has now clarified that it just needs to be doable inside of an iteration. Both of these definitions scare me a little. Probably because I think of a “feature” as the big thing that a customer wants eg “Manage my accounts”. Most people outside of Scrum these days are using a Feature -> Epic -> Story -> Task breakdown (or something similar). The Story (or User Story) should be no bigger than a Sprint. Ideally the Story should be around 2-3 days in length – why? So that demonstrable results are being showed very frequently, ie the feedback loop is tight. A feature could be made up of potentially dozens of Stories that cross multiple Sprints. A Feature Progress Chart (or Parking Lot diagram in FDD) provides a visual cue as to how well this feature’s delivery is progressing.
  • I do appreciate the approach that Features further (ie lower in priority) out need less elaboration or breaking down. In this respect all Features need a high level estimate on them but only as they get closer to being put in a sprint does the breakdown need to occur. The reason for this is that it is ultimately waste to break down work that is only possibly going to be done. Elaborate just enough, just in time.

Sprint Backlog

In the 2007 pdf we have the Sprint Backlog defined as:

The Sprint Backlog defines the work, or tasks, that a Team defines for turning the Product Backlog it selected for that Sprint into an increment of potentially shippable product functionality. The Team compiles an initial list of these tasks in the second part of the Sprint Planning meeting. Tasks should have enough detail so that each task takes roughly four to sixteen hours to finish. Tasks that are of longer estimated time are used as placeholders for tasks that haven’t been finely defined. Only the team can change the Sprint Backlog. The Sprint Backlog is a highly visible, real time picture of the work that the team plans to accomplish during the Sprint. The rows represent Sprint Backlog tasks. The columns represent the days in the month of the Sprint. Once a task is defined, the estimated number of hours remaining to complete the task is place in the intersection of the task and the Sprint day by the person working on the task.

In both March 2007 and March 2009 the Sprint Backlog definition was:

The Sprint Backlog is an artifact of the Sprint Planning Meeting. When the Scrum Team has selected and committed to deliver a set of top priority features from the Product Backlog, the Product Backlog’s features are broken down into a Sprint Backlog: a list of the specific development tasks required to implement a feature. These tasks are broken down into pieces that will require less than two days (or sixteen developer-hours) of work. When the Sprint Backlog is complete, the total work estimated is compared with original estimates from the Product Backlog. If there is a significant difference, the team negotiates with the Product Owner to get the right amount of work to take into the Sprint with a high probability of success.

In September 2010:

The Sprint Backlog is a list of tasks to turn the Product Backlog for one Sprint into an increment of potentially shippable product.

Within scrum.org the definition is now:

The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality.

The Sprint Backlog defines the work the Development Team will perform to turn Product Backlog items into a “Done” Increment. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

Monitoring Sprint Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog items can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum. The Development Team tracks these sums daily and projects the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest.

Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s Definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it. 

The ScrumAlliance definition of the moment is:

Sprint backlog: set of work from the product backlog that the team agrees to complete in a sprint, broken into tasks.

A sprint backlog is a negotiated set of items from the product backlog that a team commits to complete during the timebox of a sprint. Items in the sprint backlog are broken into detailed tasks for the team members to complete. The team works collaboratively to complete the items in the sprint backlog, meeting each day (during a daily scrum) to share struggles and progress and update the sprint backlog and burndown chart accordingly.

Sprint Backlog results and opinion

  • This wider community belief of breaking work down into Feature -> Epic -> Story -> Task is muddying the ‘task’ definition. For me a task is something more fine-grained then Scrum’s definition. It doesn’t add value and it is there more for the developer to be able to track the things that they have to do – eg “Create a new business object and update the Customer business object”. But to take Scrum’s definition as a clear rule for Scrumists then Feature will always be done inside of a single Sprint which makes the fact that there was ever a debate on which Sprint components get visualised a little strange. Regardless, the whole concept of pulling in a Sprints worth of work and  progressively demonstrating delivery is truly magical.
  • Sprint goals. I have mixed feeling on this concept. The sprint goals for me should be “get through all the work that we pulled in at the start of the Sprint”, after all, it is about working software. To have a meta-goal I feel muddies the waters. Deliver to commitments. If the above references to sprint goal is purely to deliver the features that were committed then I have no problem with it – I just hear various interpretations of this around.
  • A Sprint is a sacred timebox. I am confused by Scrum.org’s recent definition. It seems to elude to the fact that scope can just be added and removed by the Development Team without concern. If it is talking about exceptional circumstances whereby the team finishes all the committed to features then that is fine, but change inside of the iteration should not be a norm. It is a timebox to deliberately reach commitments and to push out external factors (such as Product Owners that want change every day).

Burn Down Chart Burning it up

In the 2007 pdf we have the Burn Down Chart defined as:

A burndown chart shows the amount of work remaining across time. The burndown chart is an excellent way of visualizing the correlation between the amount of work remaining at any point in time and the progress of the project team(s) in reducing this work. The intersection of a trend line for work remaining and the horizontal axis indicates the most probable completion of work at that point in time. The burndown chart helps me to “what if” the project by adding and removing functionality from the release to get a more acceptable date, or extending the date to include more functionality. The burndown chart is the collision of reality (work done and how fast it’s being done) with what is planned, or hoped for.

Incidentally the picture provided within the pdf is of a Release Burn Down not a Sprint.

In both March 2007 and March 2009 the Burn Down Chart definition was:

The Burndown Chart shows the cumulative work remaining in a Sprint, day-by-day.

At the Sprint Planning Meeting the Scrum Team identifies and estimates specific tasks that must be completed for the Sprint to be successful. The total of all Sprint Backlog estimates of work remaining to be completed is the cumulative backlog. When tasks are completed as the Sprint proceeds, the ScrumMaster recalculates the remaining work to be done and the Sprint Backlog decreases, or burns down over time. If the cumulative Sprint Backlog is zero at the end of the Sprint, the Sprint is successful.

The Product Backlog items brought into the Sprint are fixed for the duration of the Sprint. However, the Sprint Backlog may change for several reasons:

  • The development team gains a better understanding of work to be done as time progresses and may find that they need to add new tasks to the Sprint Backlog to complete the Product Backlog items selected.
  • Defects may be identified and logged as additional tasks. While these are viewed primarily as unfinished work on committed tasks, it may be necessary to keep track of them separately.
  • The Product Owner may work with the team during the Sprint to help refine team understanding of the Sprint goal. The ScrumMaster and Team may decide that minor adjustments that do not lengthen the Sprint are appropriate to optimize customer value.

The Burndown Chart is used as a tool to guide the development team to successful completion of a Sprint on time with working code that is potentially shippable as a product.

In September 2010:

A burndown is a measure of remaining backlog over time. A Release Burndown measures remaining Product Backlog across the time of a release plan. A Sprint Burndown measures remaining Sprint Backlog items across the time of a Sprint.

Within scrum.org the definition is embedded within the Product Backlog definition:

Monitoring Progress Toward a Goal

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least for every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.

Various trend burndown, burnup and other projective practices have been used to forecast progress. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making.

The ScrumAlliance definition of the moment is again sparse with:

Burndown chart: at-a-glance look at the work remaining (can have two charts: one for the sprint and one for the overall project). 

Burn Down Chart results and opinion

  • Looking over the Burn Down Chart artifact you would be excused to be confused about what is happening with it. First it was just a Sprint Burn Down, then it was Sprint and Release Burn Down, then it was for scrum.org back to just a Sprint Burn down and Scrum Alliance have it as both. It explains why there is so much mixed information and approaches in the community.
  • Personally I have always disliked how both the Sprint Burn Down and the Release Burn Down have, for lack of a better term, burnt down. To easily differentiate the two I have always made the Release a ‘Burn Up’ chart. It also tends to work better burning up then down due to the way the scope line changes.
  • Scrum.org’s removal of the Release Burn Down (Up) is strange. It is explained in their recent FAQ but if I was going to choose between the two and which one was more important I would have put my money on the Release Burn Up. When you have a good wall with all of your cards on it, it is pretty easy to see at any point in time whether you are going to achieve your Sprint commitments. With a list of Product Backlog cards on the wall it isn’t as easy to see whether you are going to meet your Release commitments. Some would say that the Release is impossible to commit to. Try seeing how easy that is to say when you are a Vendor. What the Release Burn Up does is demonstrates whether you are on track or not based upon current achieved velocity and predictive velocity. You can have conversations earlier about the scope, about the time and about the cost of the project.

Anything else?

  • I feel a few crucial artifacts are missing. There is nothing about where Business Cases fit into this picture. There is nothing about the conversations that need to be made about what is more important for the Product Owner – scope, time, cost or quality (some would argue quality is non-negotiable). Admittedly this is something of an organisation’s governance process and could be seen to be irrelevant but for some crazy reason in most places where I see Scrum being applied at the enterprise level these basic governance artifacts are one of the first things thrown out the window because ‘Scrum says we don’t do that stuff’.

With one more blog to go in this series, we have seen how Scrum has evolved over the years, soon we will see how it hasn’t.

Read Full Post »

In Part 1 of Scrum evolution over time we looked at the high level overview of Scrum and how it has changed over the years. In part 2 we looked at the roles and how they have adapted, or not, over the years. It is now time to have a look at the key activities and ceremonies.Epic Ceremonies

There are three – five key activities or ceremonies in Scrum (depending on how you take content on the sites), but more often then not it is represented as only three: Sprint Planning Meeting, Daily Scrum Meetings and the Sprint Review Meeting. The additional two sometimes considered separate are the Sprint Retrospective and the Sprint itself.

Sprint Planning Meeting

The original June 2003 site did not have a reference to Sprint Planning.

In the 2007 pdf we have the Sprint Planning Meeting defined as:

Takes 8 hrs. First four are spent with the PO presenting the highest priority product backlog to the team. Allows questions, etc. Then team selects as much Product Backlog as it believes that it can turn into a completed increment. 2nd four hours the team plan out the sprint, creates design.

In both March 2007 and March 2009 the Sprint Planning Meeting definition was:

The Scrum begins when enough of the Product Backlog is defined and prioritized to launch the first thirty-day sprint. A Sprint Planning Meeting is used to develop a detailed plan for the iteration. It begins with the Product Owner reviewing the vision, the roadmap, the release plan, and the Product Backlog with the Scrum team. The team reviews the estimates for features on the Product Backlog and confirms that they are as accurate as possible. The team decides how much work it can successfully take into the sprint based on team size, available hours, and level of team productivity. It is important that the team “pull” items from the top of the Product Backlog that they can commit to deliver in a thirty-day sprint. Pull systems have been shown to deliver significant productivity gains in lean product development.

When the Scrum team has selected and committed to deliver a set of top priority features from the Product Backlog, the Scrum Master leads the team in a planning session to break down Product Backlogs features into sprint tasks. These are the specific development activities required to implement a feature and form the Sprint Backlog. This phase of the Sprint Planning Meeting is time-boxed to a maximum of four hours.

Within scrum.org the definition is now:

The work to be performed in the Sprint is planned at the Sprint Planning Meeting. This plan is created by the collaborative work of the entire Scrum Team.

The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings.

The Sprint Planning Meeting consists of two parts, each one being a time-box of one half of the Sprint Planning Meeting duration. The two parts of the Sprint Planning Meeting answer the following questions, respectively:

  • What will be delivered in the Increment resulting from the upcoming Sprint?
  • How will the work needed to deliver the Increment be achieved?

 << Some depth is then made on these two bullet points where the “Sprint Goal” term is introduced for the first time >>

The ScrumAlliance definition of the moment is again sparse with:

Sprint planning: the team meets with the product owner to choose a set of work to deliver during a sprint.

 Sprint Planning Meeting results and opinion

  • Planning didn’t matter back in the turn of the millennium!
  • Thank goodness we don’t have 8 hr planning meetings anymore. Well, we probably still do but most of it is hidden these days. Lets say your Sprints are fortnightly. Each fortnight you are still likely to spend two hours of planning and backlog management. Then we spend a little time pulling in the right amount of work and talking about it. Hmm I could maybe stretch that out to three hours a fortnight.
  • Design; well I haven’t seen that done intensively in a meeting for quite a while. Normally that is done real time as the story is picked up by a developer. It isn’t really a meeting, not in the Feature Driven Design sense of doing some real design work collaboratively. Maybe this is more of a hangover from trying to culturally shift people’s thinking away from massive design efforts and giving them an olive branch to hold onto.
  • There is absolutely no detail regarding “how-to’s”. Nothing on how to estimate and nothing on how to get a feature backlog in the first place. The term “velocity” isn’t used to indicate the amount of “pull” of work into the iteration, but it is hinted at. This is somewhat understandable given that all the data captures were taken from overviews but even then scrounging around to find the detail is piecemeal.
  • Still hate the usage of “Features” and “Tasks” without any reference *anywhere* to user stories or even potentially epics.
  • There is no indication about what is a good size for these tasks or how to break work down.
  • Nothing mentioned about ensuring that work is not allocated to the team within this meeting.

Daily Scrum Meeting

The original June 2003 site has the Sprint Planning Meeting as:

A short daily meeting where the team shares status.

  • During the sprint, the team conducts daily scrum meetings.

  • The meetings are held in the same place at the same time every work day.

  • The meetings don’t last for more than 30 minutes.

  • A scrum master is appointed.

  • The scrum master is responsible for asking every team member the following three questions:

    1. What have you done since the last scrum meeting?

    2. What has impeded your work?

    3. What do you plan on doing between now and the next scrum meeting?

  • Conversation is restricted to the team members answering the above questions.

  • Meetings can be established for immediately after the scrum meeting based on answers to the above questions.

  • The scrum master is responsible for making decisions immediately, if required to remove impediments to progress.

  • The scrum master is responsible for noting impediments that must be resolved external to the meeting and causing them to be removed.

In the 2007 pdf we have the Daily Scrum Meeting defined as:

Every day the team gets together for a fifteen minute meeting called a Daily Scrum. At the Daily Scrum, each Team member answers three questions: What have you done on this project since the last Daily Scrum meeting? What do you plan on doing on this project between now and the next Daily Scrum meeting? And, what impediments are in the way of you meeting your commitments toward this Sprint and this project? The purpose of the meeting is to synchronize the work of all team members daily and to schedule any meetings that the Team needs to forward its progress. The team members are inspecting each others work in light of the team’s commitments, and making adaptations to optimize their chance of meeting those commitments.

In both March 2007 and March 2009 the Daily Scrum Meeting definition was:

Once planning is complete, the Sprint begins its thirty-day cycle. Each day the Scrum Master leads the team in the Daily Scrum Meeting. This is a fifteen-minute meeting designed to clarify the state of the Scrum. Each team member speaks to three questions: what did I do yesterday, what did I do today, and what impediments got in my way? While anyone can attend this meeting, only team members who have committed to deliver work to the Scrum are allowed to speak. The goal is to get a global snapshot of the project, discover any new dependencies, address any personal needs of committed individuals, and adjust the work plan in real time to the needs of the day. Within scrum.org the definition is now:

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.

The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, each Development Team member explains:

  • What has been accomplished since the last meeting?
  • What will be done before the next meeting?
  • What obstacles are in the way?

The Development Team uses the Daily Scrum to assess progress toward the Sprint Goal and to assess how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. The Development Team often meets immediately after the Daily Scrum to re-plan the rest of the Sprint’s work. Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated Increment in the remainder of the Sprint.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.

The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum. The Daily Scrum is not a status meeting, and is for the people transforming the Product Backlog items into an Increment.

Daily Scrums improve communications, eliminate other meetings, identify and remove impediments to development, highlight and promote quick decision-making, and improve the Development Team’s level of project knowledge. This is a key inspect and adapt meeting. 

The ScrumAlliance definition of the moment is still sparse with:

Daily scrum: the team meets each day to share struggles and progress.

Daily Scrum Meeting results and opinion

  • I want to call out the usage of the word ‘Daily’ here. A Scrum Meeting doesn’t have to be daily. I have seen many highly functional teams performing fine with two or three scrum meetings a week. Do I generally recommend daily? Yes. But it depends on the size of the team and the amount of interaction that is actually needed. Some teams are naturally good at communicating all of the time. Sometimes (especially for non software development teams) the landscape doesn’t change so quickly that a daily discussion is required.
  • XP called then stand-ups as did Ritz hotels (doing them back in 1998). But it does seem that Scrum was the first to record the format and espouse it’s value. The term ‘scrum’ here frustrates me. It is a cutesy name that has been applied to something that commercially is more viable if you just call it a ‘stand-up’. The ‘stand-up’ name itself infers the quick nature of the meeting. By standing up members are encouraged to keep the meeting brief and to the point. The visual cue of boredom via fidgeting is heightened. The blue sky term ‘huddle’ equally frustrates me.
  • Maybe initial scrum meetings weren’t held standing up – after all 30 minutes is very long! These days I am happy if they go for 10 minutes and I start to fret when they hit 15 minutes. A 15 minute stand-up is a clear indication to me that a team that might not being doing the activity daily needs to do it more frequently.
  • Scrum Meetings are hard to get right. It takes a delicate balance of control and autonomy to grow the team’s capability in self sustaining these meetings. Discussions can hint at emergent conflict or team dysfunctions. There is more to running these sessions then just the brief list of objectives hinted above (and more value then hinted above as well). I recently did a decision tree for Scrum Masters when running the Scrum Meeting to help guide them of the sorts of questions and thoughts that they should be considering at the start of the Scrum Meeting, whilst each individual is talking and at the end. It ended up being a three page tree with over 25 nodes. That in itself surprised me. I would love to see more useful guidelines to Scrum Masters about how to facilitate effective Scrum Meetings.
  • I am frustrated by usage of language like the “Scrum Master is responsible for asking every team member…” This is a team meeting not a Scrum Master meeting and it sets an incorrect presumption that discourages an environment of autonomy that the Scrum Master is trying to establish. Each individual in the team is responsible for answering the three questions, the Scrum Master is accountable to ensure that they follow through on that responsibility.
  • I mentioned in the roles post that I differentiate between the core team and the extended team. It is the core team that is required to provide answers to the three questions. The extended team is invited to attend and may speak but they should not take over the show. I believe it is unfair that extended team members by the above definition are unable to even ask questions. Would you really stop the person who is potentially paying for your product development from asking a question regarding the scope boundary of a particular story?
  • There is no mention of a wall (physical or virtual) which is a missing key element of this ceremony overview. It is a smell when team’s talk about the work but never refer to it by touching their cards. Touching their cards ensures that everyone clearly knows which story they are talking about and can more effectively contextualize the conversation. Likewise I would always recommend that mid iteration the team additional walks the wall – talking through every card that is not done to ensure that the sprint goals are re-ignited in their minds. This is a key technique that the overviews are missing.

Sprint Review Meeting

In the 2007 pdf we have the Sprint Review Meeting defined as:

At the end of the Sprint, a Sprint Review meeting is held. This is a four-hour timeboxed meeting where the Team presents what was developed during the Sprint to the Product Owner and any other stakeholders that wish to attend. This is an informal meeting, with the presentation of the functionality intended to foster collaboration about what to do next based on what the Team just completed. The Product Owner and stake holder inspect the Team’s work in light of project goals, and make adaptations to optimize their chance of reaching those goals.

In both March 2007 and March 2009 the Sprint Review Meeting definition was:

At the end of a sprint, a Sprint Review Meeting is held. This meeting is time-boxed to a maximum of four hours. The first half of the meeting is set aside to demonstrate to the Product Owner the potentially shippable code that has been developed during the sprint. The Product Owner leads this part of the meeting and invites all interested stakeholders to attend. The state of the business, the market, and the technology are reviewed. The Product Owner determines which items on the Product Backlog have been completed in the Sprint, and discusses with the Scrum team and stakeholders how best to reprioritize the Product Backlog for the next sprint. The goal for the next sprint is defined.

After the Scrum Review Meeting, the process begins again. Iterations proceed until enough features have been done to complete or release a product.

Within scrum.org the definition is now:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. This is an informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

This is a four-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints. For example, two week Sprints have two-hour Sprint Reviews.

The Sprint Review includes the following elements:

  • The Product Owner identifies what has been “Done” and what has not been “Done”;
  • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
  • The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
  • The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date; and,
  • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

The ScrumAlliance definition of the moment is sparse with:

Sprint reviews: the team demonstrates to the product owner what it has completed during the sprint. 

Sprint Review Meeting results and opinion

  • Not much has really changed for the Sprint Review Meeting over time and it probably didn’t need to that much. Personally I prefer having the backlog always prioritised correctly at all times and so a portion of this description is less applicable. That said some people would argue that the intent is the re-prioritise the work that didn’t get done. For me this is a smell and the overview of the process really shouldn’t be handling this exception. The goal is to deliver all of the stories. It should be a realistic goal and in that respect there should not be the need to re-prioritise the work that did not get completed.
  • Who is doing what is also less black and white then what is defined above. Why can’t the Product Owner demonstrate what is done? Why can’t the Product Owner and Scrum Master contribute to what went well?

Sprint Retrospective

In the 2007 pdf we have the Sprint Retrospective defined as:

After the Sprint Review and prior to the next Sprint Planning meeting, the ScrumMaster holds a Sprint Retrospective meeting with the Team. At this three hour, timeboxed meeting the ScrumMaster encourages the team to revise, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint.

In both March 2007 and March 2009 the Sprint Retrospective definition was:

The second half of the Sprint Review Meeting is a retrospective for the Scrum team that is led by the ScrumMaster. The team assesses the way they worked together in the sprint and identifies positive ways of working together that can be encouraged as future practice. The team also identifies the things that could work better and develops strategies for improvement.

Within scrum.org the definition is now:

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning Meeting. This is a three-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints.

The purpose of the Sprint Retrospective is to:

Inspect how the last Sprint went with regards to people, relationships, process, and tools;

Identify and order the major items that went well and potential improvements; and,

Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of “Done” as appropriate.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation. 

The ScrumAlliance’s definition:

Sprint retrospectives: the team looks for ways to improve the product and the process. 

Sprint Retrospective results and opinion

  • Early versions of Scrum don’t have Retrospectives as a key ceremony as it was taken from Norm Kerth’s Project Retrospectives and Alistair Cockburn’s Reflective Workshops. By the time it was incorporated into Scrum it was a norm for all of the other Agile frameworks.
  • Popular believe now is that Scrum is all about “inspect and adapt”. Most people immediately think that this pertains to the stories that are delivered but the reality is it is both the work that is being delivered and how it is being delivered.
  • Often the Sprint Review and Retrospective are lumped together and commonly this is why Scrum has kept to the “three ceremony” belief. But the reality is the purpose of the meeting is different from the review and it should be considered a separate ceremony.
  • Common failure modes in Retrospectives include a lack of follow up on the retrospective actions or too many actions chosen for resolution. The lack of details about how to conduct this activity would not mitigate these common failure modes. Personally I either make the actions (limited to no more than five) new stories or ensure that at the beginning of the next retrospective they have been completed.
  • Nothing about true root cause analysis is described. This would be another failure mode – fixing the wrong problem.
  • When the team is familiar with the format of the retrospective I would rotate the facilitation role to further encourage autonomy. It doesn’t always have to be the Scrum Master that facilitates this session.
  • If the Retrospective Quadrant technique is used there are very common quadrant patterns based upon the life of the project. Early in the project there is a lot of points around ‘puzzles’ and ‘what is not working/what to do differently’. As the project progresses the numbers shift from the right side to the left. A lack of a shift or a resurgence of puzzles is commonly indicative of a team dysfunction. Often I see a lack of clarity around roles and responsibilities in the ‘puzzles’ area. If a new team member is added it tends to come back again as the team goes through the forming, norming, storming and performing behaviours.

The Sprint itself

In June 2003 a Sprint was defined as:

A short burst of work lasting approximately 30 days during which an executable and other deliverables are built by an engineering team, as indicated by the assigned backlog.

  • A sprint lasts no more than 30 days.
  • A sprint is undertaken by a cross functional team consisting of no more than 9 members.
  • Every sprint has a specific goal.
  • An executable demonstrating the goal will be completed by the team during the sprint.
  • The sprint team has final say in estimating and determining what they can accomplish during the sprint.
  • Once the sprint is underway, new backlog cannot be added to the sprint except that, if the scrum master determines that a new backlog item will enhance the viability of the product, is in alignment with the sprint, builds on the sprint’s executable, and can be completed within the sprint’s time frame, the backlog item can be added. Examples are building a demonstration of the executable for a specific purpose, such as a trade show or prospect.
  • If external forces determine that the sprint is working on the wrong thing, a sprint can be halted and restarted with new backlog and purpose.

In the 2007 pdf  there was no separate section defining a Sprint other than it being one month.

In September 2010 the Sprint definition was:

The heart of Scrum is a Sprint, which is an iteration of one month or less that is of consistent length throughout a development effort. All Sprints use the same Scrum framework, and all Sprints deliver an increment of the final product that is potentially releasable. One Sprint starts immediately after the other.

Within scrum.org the definition is now:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

  • No changes are made that would affect the Sprint Goal;
  • Development Team composition remains constant;
  • Quality goals do not decrease; and,
  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

 Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog Items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone has to regroup in another Sprint Planning Meeting to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

 The ScrumAlliance has no separate definition for the Sprint.

Sprint results and opinion

  • I’ve talked about the 30 days before so I won’t go there again.
  • I don’t think enough people understand that the Sprint itself is a sacred timebox. Change is not meant to be put inside of the Sprint with the exception of potentially cancelling a Sprint. This is a weakness and a strength at the same time for Scrum. A strength because it forces the Product Owner to control themselves, a weakness because for some areas of software development waiting a Sprint to change is commercially too long. In these instances most Scrum Masters would then recommend a shorter Sprint length, but in some respect it is not addressing the root cause of the problem – it is providing a framework to somewhat mitigate it.
  • It is unrealistic to assume that development team composition will remain constant. In this day and age of rapid change the framework needs to handle and be able to solve this problem. Onboarding will happen. We all know it probably shouldn’t but this is a commercial reality.
  • I’m not sure about the wording on the scope being clarified bit. Yes a story is a promise for a conversation and in part of this conversation the scope will have clarification, but what if the developer realises that the story is now four times bigger then expected – the whole goal of the Sprint is in potential jeopardy. Scope should be known enough when the Sprint Planning has concluded so that the team will be able to deliver to it’s Sprint goals. Any changes to scope subsequent to this should be minor. Remember – the Sprint is a sacred timebox away from dramatic change.
Anything else?
  • I really dislike the terms ‘scrum’ and ‘sprint’. They were hard terms to sell to management in the mid-early 2000s, they are even harder terms to sell outside of software development where as a framework it is still really useful. Call them “iterations” everyone else does. No-one literally group hugs to form a ‘scrum’ (despite there being evidence to prove that this will result in more effective outcomes). Terminology complaints have been going for a long time now and still there is no change. A number of organisations have to call their implementations something else to get around these non commercially acceptable terms.
  • I really dislike the term ‘ceremony’. It is a meeting or even better a repeatable process activity. This is another example of a term being used to make Scrum sound ‘cute’ when really it needs to take itself more seriously.

Read Full Post »

Follow

Get every new post delivered to your Inbox.

Join 920 other followers