I’m pleased to announce that I’m making the full text of ‘Switching to Scrum’ available as a downloadable PDF. Feel free to download it and share with your friends and associates. I’m always open to feedback on the content and welcome anyone to write me at:

I’ve been contemplating how to apply Kanban techniques at my work and found the concepts of Scrumban to be quite interesting. In Scrumban, the best of both techniques are combined into a methodology that provides visibility, flexibility and removes the constraints of planning for and completing work within sprints.

The material on the Internet wasn’t always clear or comprehensive and typically focused only one aspect or another. What I was looking for was a guide on how to switch to Scrumban and so after researching and some experimentation, I created my own Implementing Scrumban whitepaper.

The whitepaper is available in PDF format. Feedback is welcome and I will incorporate any good ideas back into the whitepaper.

(The following is an edited excerpt from my upcoming book: “The Product Owner Role Explained”.)

When an initiative starts, there’s always interest in knowing when it will be completed. Certainly the Management team would want to know and the Product Owner himself may need estimates for Roadmap planning or coordinating with other parts of the organization. Under the Scrum methodology estimates for an entire initiative aren’t provided up front so how can the probable completion date be determined?

An easy, quick and low effort technique is to create an Initiative Burndown Chart which tracks the number of remaining backlog items from sprint to sprint. It provides a clear visual showing progress and the sprint in which all work is likely to be completed.

Creating the chart is best done using a spreadsheet although given its simplicity, it could also be done on a whiteboard or poster-board hanging in the Scrum Team’s regular meeting area. Start with a three column table with Sprint #, Sprint Start Date, and Remaining Backlog Item Count. Then create a bar chart that plots the number of remaining items for each sprint. A chart like the following can be created:

Updating the chart is a matter of counting the remaining backlog items after Sprint Planning. Why after this meeting? Because by the time that meeting is over, the Developers would have given feedback on the Product Backlog at a Story Time meeting and during Sprint Planning and any new items would be defined at least by title. The key with using this technique is to update it in a consistent way, either always right after Sprint Planning or at the end of that day.

Notice that the chart has a dotted straight line running from the highest bar and projected downwards until it reaches zero. This trendline represents the likely sprint in which all initiative work will be complete. In the above example, the Scrum Team had worked for six sprints and probably needs three more to be completely done. Assuming they finish all the work in Sprint 9, the predicted completion date would be by Sprint 10 or August 14.

Of course the Product Backlog isn’t static and so the number of backlog items can increase over time. When this occurs, as illustrated in the following, the trendline is redrawn from the new highest bar towards zero. This bump in backlog item count has changed the date when all work is likely to be completed and so the predicted completion date coincides with Sprint 11, or August 28th.

The predictive power of this chart isn’t perfect as it doesn’t take in account the size of the backlog items but since a Product Owner doesn’t want the Scrum Team to spend a couple of sprints only estimating backlog items, that may not even be fully defined yet, it’s a good alternative to guessing.

Besides the obvious benefits of predicting when an initiative will be completed, the chart can also be a great motivator. When a Scrum Team is starting a 40+ backlog item initiative, it may feel like an insurmountable mountain of work lies ahead and so showing progress from sprint to sprint will give them a sense of where they’re at in the whole effort and may even inspire them to get it done quicker.

the assembly of the Scrum Team, at the end of every sprint, where the Developers demonstrate completed work to the Product Owner for acceptance. Usage: Let’s not be late for the Sprint Review Meeting.

Based on the above definition for the Sprint Review meeting, one might imagine these are dull and lifeless events, full of techno-babble, acronyms, and the examination of code.

In reality they don’t have to be. After all, the backlog items represent “business value” so the demonstrations can focus on that. No matter the nature of the completed work, whether it’s a webpage, or application user interface or backend business logic, it can be demonstrated in a compelling way.

The key is to think about telling a story, which includes setting the context, describing the challenge and revealing the outcome. Considering that anyone in the organization could attend the Sprint Review Meeting, this is an opportunity for the Developers to impress the audience with their technical skills and showmanship.

Before the Sprint Review Meeting

Plan the Demonstration – Before the Sprint Review meeting, the Developers should decide who will demonstrate what and when. Also the team should identify and obtain any special hardware, tools, access or configuration necessary to facilitate showing their work.

During the Sprint Review Meeting

Identify the Backlog Item(s) to be Demonstrated – At the Sprint Review, start by identifying which backlog item is about to be demonstrated. The Product Owner is probably very familiar with each of them but by calling them out explicitly (e.g. ID#, title, or user story), it will help prepare him to evaluate the work. Sometimes it makes sense to demonstrate more than one backlog item at the same time. In these cases, it should be made clear that multiple items will be covered.

Summarize the Backlog Item – Briefly describe what the backlog item was asking for so any attendees who aren’t regularly tracking sprint work can understand what they’re about to see. The description may not be necessary for the Product Owner but he will appreciate knowing that the Developers understood what he was looking for.

Set the Stage – The best way to illustrate completed work is to show what existed before. For example, if a user interface was modified, show the old version first; if the backlog item calls for new files to be created, show that they didn’t exist before. Focus on this aspect just long enough to establish the starting point and give the audience a sense of what will be changing.

Describe the Implementation – Briefly describe how the backlog item was implemented as a lead-in to showing the results. Hold back on the details unless specifically asked or the Sprint Review meeting will lose focus and may not finish within the time allotted.

Show the End Result – Demonstrate what was created for the backlog item, pointing out those aspects that specifically meet the acceptance criteria. If the Developers cannot figure out how to best demonstrate the work, ask the Product Owner before the meeting as he may want to see something specific to be satisfied.

Solicit Questions – Open the floor up for questions but make sure the Product Owner has the opportunity to ask if he has any. Be mindful not to lose track of why everyone is there and table any unnecessary technical discussions until a later time.

Obtain a Definitive Answer – Lastly, if the Product Owner doesn’t explicitly state it, ask if he accepts the work. If the acceptance isn’t definitive or he outright rejects it, ask what he thought was missing so the team can figure out where the disconnect was.

“[2] Hello everyone, I’m going to demonstrate item #B-042, [3] which gives the website user the ability to have the username remembered for up to two weeks. [4] Here’s what the login page looked like beforehand, notice there’s no option for having the site remember the username. [5] To achieve this, we used cookies with a short script and worked with the graphics design guys to make it look nice. [6] Here’s what it looks like implemented and we can step through enabling and disabling the feature. [7] Well, that’s it; are there any questions? [8] Does the Product Owner accept the work?”

Based on the above example, all the guidelines don’t have to result in a long winded presentation for each backlog item. The key is to cover the essential elements that make for telling a good story.

Developers should remember that while the purpose of the Sprint Review meeting is to demonstrate completed work, it represents a great opportunity to impress others with their skills. The best Developers are those who can deliver solutions and interface well with the business side of the organization.

When a backlog item is first added to a product backlog, rarely will it be in its final form. At a minimum the user story (u/s) and acceptance criteria (a/c) will change as the Product Owner works on refining the business value each item describes.

Later, when the Scrum Team has an opportunity to preview each backlog item during a Story Time meeting, even more dramatic changes may be required. This is because the team will be thinking about how the item might be implemented and make suggestions according to their theoretical approach. They may recommend splitting the item into two because of size, or the discussion will result in new backlog items spawning from the original idea. Combining items may also be suggested where the team believes they can gain efficiencies.

The following sections explain the different types of metamorphoses, when they might occur and why.

Splitting the Backlog Item

Sometimes a backlog item represents a scope greater than what can be completed by a Scrum Team during a sprint. The obvious thing to do is to split it up into two or more items but therein lies the challenge, how can it be divided?

The first area to look at is the user story (u/s) to see if the business value it describes is defining functionality at too high a level. For example, a backlog item that describes a user’s ability to log into a website and include the functionality to recover their username/password might be split between logging-in and account-recovery functions. Yes, they are both essential to a complete website experience but arguably, having the ability to log in is more valuable and therefore could be separated and completed first.

The second area to look at is the acceptance criteria (a/c) to see if they represent more than one theme. Returning to the example of a function that enables a user to recover their username/password, the acceptance criteria could be separated into two groups, one for usernames and the other for passwords each within their own backlog item.

Spawning a New Backlog Item

When a backlog item has dependencies necessary to either begin or finish the work, new items may be spawned and placed at a higher priority to ensure they are completed first. This could include a research spike to give the Scrum Team time to learn about a technology, design work on a database, or prototyping to decide what the final strategy will be.

Newly spawned backlog items aren’t only for prerequisites, they can also reflect work necessary as a result of completing the original backlog item. For example, if a website was going to collect statistics on performance then someone will want a report or interface to access the data later.

Combining Backlog Items

As a Scrum Team looks ahead at upcoming backlog items they may see patterns in the requirements or how implementation might proceed. Combining backlog items could make sense in order to gain efficiencies in either the coding or testing necessary to complete the work.

For example, if a backlog item described enhancing the monthly sales report to include commissions paid out and a completely different item described adding a column for partner revenue sharing totals, the Developers may want to complete both enhancements within the same item because to “open the hood” on the reporting engine is time consuming and doing it once is preferred.

I was watching a television show recently about Air Traffic Controllers and how their job has evolved over time. It was interesting to note that their job has been basically the same since the beginning where they have to track many planes at once and service each one’s specific needs. In thinking about this, it struck me that the role of Product Owner is much the same.

Of course it is well known that the Product Owner is responsible for preparing the Product Backlog for Sprint Planning but there much more than that. A Product Owner represents business needs and is a conduit for requests from the smallest of defect fixes, to product enhancements, to completely new initiatives.

All these requests must flow through a process managed by the Product Owner which is where my analogy of an Air Traffic Controller comes in. The following illustration helps to explain the comparison. There are four “zones” a Product Owner must pay attention to, giving each a slice of his overall time and making sure not to leave any one unattended for very long. The successful completion of a request is dependent on the Product Owner managing all four zones so that each request can “land” and call the journey complete.

Zone 3 – In a Holding Pattern

All work for a Scrum Team begins by entering Zone 3 regardless of whether the Product Owner himself created it or it was a request from elsewhere in the organization. These requests will typically be unstructured and contain varying levels of details. They could be merely vague ideas mentioned in passing by a coworker in the hallway: “We should do something about that problem we had last week.” or be very specific requests: “I need a tool to decrypt files for diagnosing problems.”

When the Product Owner receives these requests there’s a minimum set of information that should be captured.

What is being requested.

Why it is wanted.

Who is requesting it.

The urgency level.

Who can be contacted for additional details.

This information will be used to triage requests and help determine its place in the Product Backlog. When the request is larger in scope or will be visible to the business, it should also be tracked on the Product Roadmap.

As these requests collect, the Product Owner will need to dedicate time to grooming them, refining what is wanted by spending time with the requester. When the Product Owner has enough of an understanding of what’s needed, he’ll be able to create a series of backlog items representing the original request.

Zone 2 – Forming Up for Approach

The backlog items in Zone 2 now represent the request but they will still need refinement. The Product Owner may need to create a project kickoff presentation, data lookup tables, final copy (text), mockups of user interfaces, et cetera. These additional elements will be necessary for the Scrum Team to fully understand what each backlog item asks for. Creating all this material will consume plenty of time and may require consultation with others in the organization since the Product Owner is unlikely to be an expert in all areas.

Additionally if any backlog items require coordination with outside resources, such as the ordering of hardware or negotiating to have a resource available, the Product Owner will need to line these up.

As backlog items become complete enough to be reviewed by the Scrum Team, the Product Owner will present them during a Story Time meeting. This process may be as simple as explaining each item or giving the team a presentation regarding the big picture and what they’ll be working on. Feedback from the team will help refine each item further.

Zone 1 – On Approach

Backlog items in Zone 1 now have all associated material ready and the Scrum Team has seen and provided feedback on each one. Also, any outside resources will have been coordinated with, and committed to, providing the support needed. At this point each item’s final position can be established within the Product Backlog.

Once backlog items are in this zone, they should not be bumped from their position for the following reasons:

The Scrum Team is familiar enough with each item and any delay will result in their memories fading, requiring another review at a later time.

The Product Owner’s memory of the details may also fade, requiring he re-familiarize himself with each backlog item to be ready for Sprint Planning.

External resources (personnel, equipment, processes) have been lined up and rescheduling may not be possible in the short term.

Events or processes such as Sales Training, or an advertising campaign dependent on delivery may not be easily postponed.

Any expectations management had about delivery dates will have to be reset, potentially creating disappointment.

However, just like with real airports, where emergency situations require airline traffic be put on hold for a plane in trouble, backlog items for urgent business needs will occasionally be wedged in at the top of the Product Backlog. In these cases the Product Owner and Scrum Team will just have to deal with the new work as best they can.

Ideally Zone 1 should have enough backlog items to supply a Scrum Team with two sprints worth of work. Having this surplus ready is good for when a team’s capacity has opened up and they are willing to take on additional items. The Product Owner will have to continually focus on refining backlog items in this zone to ensure enough work is available.

Zone 0 – Landing

In this zone, backlog items have been selected into a sprint and the team is actively working on them. It is important to allow the team to complete this work but if absolutely necessary, they can negotiate a change in sprint scope.

To support Zone 0 the Product Owner will have to be available during Daily Standup meetings and address any questions or needs that come up. There will always be questions once the Developers begin implementation and no amount of preparation ahead of a sprint will eliminate them.

Managing the Airspace

A Product Owner, just like an Air Traffic Controller, will have to monitor numerous requests and backlog items throughout the process. It can be overwhelming to pay attention to so many things each day leading to a risk of burnout. A workable strategy involves blocking off time by the hour to concentrate on one of the zones at a time. For example, allocating an hour a day to Zone 3, the Product Owner may concentrate on clearing requests out of their email, and converting them into rough backlog items describing each request at high level. The same can be done for the other zones, allocating time as needed to keep everything moving.

The method of concentrating on one zone at a time can either be in the order of requests flowing through the process or randomly, whatever makes the most sense. It is important however that attention be given to all three in order to have enough work ready for the Scrum Team for the next Sprint Planning meeting.

During a sprint planning meeting, the Developers select the number of backlog items they reasonably believe they can complete within the sprint. They do this knowing that while there are specialists on the team (e.g. Coders, Testers, DBAs, Graphics Artists, Copywriters, etc), it is up to the entire team to complete the selected sprint work. This means that there will be some blurring of traditional roles with each team member helping in ways outside of their traditional role.

Sometimes sprint capacity opens up for an individual team member even after they have helped out wherever they could. In this case, what are these individual team members to do?

Of course the first action is to inform the rest of the team at the Daily Standup meeting just in case someone could use their help. Assuming their spare capacity cannot be utilized, there are always background tasks that could be done depending on their traditional role. Using the Coder or Tester roles as an example, they might do some of the following:

Learn the typical duties of other team members so they can help more in future sprints.

Coordinate with the rest of the organization so code can be deployed.

Refactor code (so long as it doesn’t impact other team members and delivery of current sprint work).

Write unit tests to improve quality before formal testing.

Update documentation and organize project files.

Look for defects in previously delivered code.

Identify technical debt and make recommendations to the Product Owner for new backlog items.

Investigate new toolsets that would benefit the team.

Create automated test case suites.

Research upcoming backlog items requirements and solutions.

Any number of activities could be done as long as the work will be beneficial for the Scrum Team now or in future sprints.