1-N List

A very good explanation:

What is it?

  • Ranked vs. Prioritized:
  • Prioritized lists are ineffective because everything ends up being Priority 1
  • A Ranked list forces a comparison between every item in the list and shows an order in which to work
  • The ranked backlog is continually groomed & refined
  • Work at the top of the list should be stable and well defined
  • Work at the bottom of the list is subject to re-ranking based on changing priorities and is only roughly sized
  • A Ranked List encourages and facilitates limiting the Work-In-Progress (WIP)
  • By controlling Theme Staging (more on that later), we control the amount of work that is fully defined and ready for work
  • The Ranking is determined by representatives from all groups during the a phase of the work whereby all the member agree that the work is defined and ready.

Why do I care?

  • Because it will make your job easier
  • You don’t need to worry about all ‘x’ number of themes planned for a release. You only need to worry about the top 1 or 2 items on your backlog at a time.
  • Sprint planning becomes much easier because you simply pull work from the top of the list until your team is at capacity for the sprint
  • You don’t have to manage conflicting priorities and requests from multiple people to work on multiple things. Focus on the top of the list and work it to completion before moving on to the next request.
  • Estimates of ‘when can you have this done?’ become very simple. Look at the # of story points in your backlog, divide by your sprint velocity (i.e. the average number of points you complete per sprint) and you can roughly predict when any given piece of work will be completed

Assuming you are really working from the top-down on one thing at a time!

The 1-n list's Staging Line

  • What is the Theme Staging Line?
  • It is the line that separates the approved but inactive backlog (bottom of the list) from the refined and sized active work (top of the list).
  • This line is denoted in the 1-N Ranked backlog by an established point in the list
  • How is it set?
  • The goal is to limit the WIP by controlling the Staging line.
  • The Staging line is set at (roughly) 3x the current sprint velocity.
  • As of today, if our velocity is around 800 story points per sprint. For easy math, we’re rounding up to 1,000 points.
  • The first 1,000 points in the list should be what you are working on this sprint.
  • The order of work in this block should not change mid-sprint.
  • The next 1,000 points in the list should be what you are working on next sprint.
  • The order of this work should not change often but can be re-ordered for urgently needed new work
  • The final 1,000 points are ‘being staged’. i.e. the theme owner is working with scrum teams to define and size the user story breakdown
  • The Staging Line is NOT a statement of what is committed or not committed for any particular Development Cycle or Release.
  • It is a continually moving line. As stories points are completed at the top of the list, new work moves up and crosses the line to become ‘active’.
  • Work below the line today does not mean it is ‘out of scope’, ‘out of plan’ or ‘will not be worked’. It simply means it will not be worked YET.
  • But wait a minute, doesn’t everyone have to be sizing their work to have a true velocity?
  • YES! YES! And YES!
  • In the example, the ~800 point velocity really only represents core development which is only a small piece of the total work needed to get a theme to production.
  • We need all the teams (anyone and everyone who has any work to do on a theme) to create user stories and size them consistently.
  • It may help if you have a 'Story Point Sizing Rule of Thumb’ or common process.

What else?

  • What if I complete everything above the line and need more work to do?
  • Congratulations! You must have been extraordinarily productive the last few sprints!
  • Now please go help your teammates complete their work. You are not done until the whole team is Done! Done! Done!
  • Please remember, the most important work, which is active and at the top of the list, needs to be completed before you begin something lower on the list.
  • Don’t we need better cross-functional teams to really make this ‘whole team’ thing work?
  • Yes! Yes! and Yes! Teaming is very important. Using Squads (a.k.a., cross-functional teams) is another area of endeavor that can help.
  • Stop Starting, Start Finishing. Unfinished Work is not very useful to anyone.
  • Having one Theme completely done is more useful to customers than having many Themes partially done. You don’t drive a car with 3 tires?
  • Use the ranked list to guide your work.
  • Say “not yet” to requests of work on something with a lower priority, or say “no” to something below the line.

Kanban

What is Kanban?

Kanban is a method for managing the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.

Kanban is based on 3 basic principles:

  • Visualize what you do (workflow): seeing all the items in context of each other can be very informative.
  • Limit the amount of work in progress (WIP): this helps balance the flow-based approach so teams don't start and commit to too much work.
  • Enhance flow: when something is finished, the next highest thing from the backlog is pulled into play

Kanban promotes continuous collaboration and encourages active, ongoing learning and improving by defining the best possible team workflow. Also, when something is finished. It is finished with Quality.

Benefits

Kanban can be summarized by: Stop Starting, Start Finishing. The team's focus should be on "getting to done" for those items in progress.

Some of the benefits of Kanban:

  • Shorter cycle times can deliver features faster.
  • Better responsiveness to changes.
  • Kanban is very good with frequently changing priorities.
  • Balancing demand against throughput guarantees that most the customer-centric features are always being worked.
  • Start-up requires less organization / room set-up changes.
  • Reducing waste and removing activities that don't add value to the team/department/organization
  • Teams are motivated, empowered and perform better with rapid feedback loops.

How is Kanban different from Scrum?

Both Kanban and Scrum focus on releasing software quickly and often. Both require highly-collaborative and self-managed teams. There are, however, differences between the two approaches:

Attribute / Kanban / Scrum
Flexibility / Changes can be made at any time. / No changes allowed during the sprint
Flow / Time-boxed sprints. Regular fixed length sprints (1-2 weeks). / Continuous flow / delivery.
Value Delivery / Continuous delivery (at team's discretion). / At the end of each sprint.
Team Roles / Pre-defined roles (e.g., scrum master, product owner, development team) / No fixed or prescribed roles
Key metrics / Cycle time / Velocity
Flow of work / Work is pulled through the system (single piece flow) / Work is pulled through the system in batches (the sprint backlog)
Appropriate when in / Operational environments with a high degree of variability in priority / Situations where work can be prioritized in batches that can be left alone
Best used where / Process flow is well understood and the team is highly optimized. / Where the process flow is not well understood so that at the end of the sprint, the team evaluates and adjusts what is required to complete the work.

Kanban is best used where the process flow is well understood and the team is highly optimized.

Kanban vs Scrum Myths and Hype by Michael DePaoli

It’s usually about degrees for true and false

Recently, I heard folks at a few of my clients and at a couple conferences talking about why they are considering moving to using Kanban vs. Scrum. I have no preference to either method other than choosing the right agile development tool for the job. My concern derived from what I have heard identifies the beginnings of some myths and also demonstrates some of the hype around Kanban.

First, a clarification; Kanban with a capital (K) is the term David Anderson coined with respect to an agile development approach to driving change based on lean principles. Kanban with a little (k) represents the idea of the “sign” or “billboard” that provides the signal/visibility in a production line for additional demand for service of a particular station. It is one of the tools that enables just-in-time (JIT) action as described in the Toyota Production System.

Kanban, as Anderson explains in his book, relies on change occurring in more of an optimizing manner (see kaizen culture).

David Anderson’s Kanban book

This is the significant difference between Kanban and Scrum. In a Kanban approach, an organization can begin with their current practices with a few exceptions. Kanban requires:

  1. A high degree of visibility into the state of all work queued and in progress
  2. Absolute respect for WIP limits
  3. A commitment to execution in a ‘pull-based’ manner from the prioritized work queue

Kanban also demands a focus on quality. In fact, this is Anderson’s first step in his six-step recipe for Kanban. Quality comes first primarily because of the obvious cause-and-effect relationship to waste — and because it’s generally more in the direct control of technical management. Working down his recipe, there tends to be less control and influence over the changes by technical management.

Now for the Myths and Hype

Myth: Scrum has work pushed onto the team while in Kanban work is pulled into the system. This is incorrect. Scrum does not have work “pushed through the system.” It is a pull-based agile development system with work pulled in larger batches (the Sprint Backlog). A Scrum implementation (as well as Kanban) becomes a ‘push-based’ system when the business doesn’t respect the current proven capability of its teams to produce value and just continues to push demands for service into the system.

Doesn’t just apply to Kanban

Hype: Kanban at its core is summarized by the premise: ‘Stop Starting, Start Finishing’. The entire team’s focus is on ‘getting to done’ for the tasks in progress. This statement is certainly true of Kanban, but the implication that Scrum does not have this focus is not true. Scrum done right has the same focus, delivering software sooner and doing so in priority order to maximize the value delivered to the customer. I’ve coached to Scrum teams for years that, wherever possible, everyone on the team should work on the highest priority item and get it done first before starting on the next item in the Sprint Backlog. This implies limiting WIP, as well as focusing on delivering the Backlog in rank order.

If the focus of a Scrum team is to just get everything in a Sprint Backlog into an in-progress state, regardless of priority, then you have a dysfunctional team that’s most likely not working cross-functionally and certainly not focused on delivering the highest-value items first.

Hype: The statement, “The Kanban method is intuitive and is quickly and easily adopted by teams,” to me is a statement that’s used irresponsibly. It is too often a battle cry of those trying to sell Kanban as a product. It is the cop-out reason used by many organizations who are failing at Scrum and looking at Kanban.

The key myths and hype behind Kanban vs Scrum. Now I’ll discuss the realities of implementing Kanban and some of the fundamentals that hold back both Kanban and Scrum implementations.

On paper, Kanban is certainly easier to kick-start from a change management perspective because you can leave current roles and processes largely intact; you just need to get commitment from the business to adhere to three basic principles:

  1. Provide a high degree of visibility/transparency of the state of all work queued and in progress.
  2. Establish and respect WIP limits in the value flow.
  3. Commit to execution in a ‘pull-based’ manner from the prioritized work queue.

Yeah, just get commitment and practice of these three things… Much easier said than done in my experience because they are frequently outside the circle of influence of those driving the change to implementing Kanban!

Usually it isn’t that the agile software teams are unable to execute under Scrum; the fundamental issue is that the business isn’t willing to accept a “pull-based” execution model (required for Kanban and Scrum).

Businesses continue to make irresponsible commitments to customers and investors. This only perpetuates crystal-ball thinking, fixed-date, fixed-scope and fixed-cost projects. It’s the classic sales-driven model we see all too often where the sales arm doesn’t respect the capability of its product development group to produce predictable value for the customer in a timely manner, and with an agreed-upon level of quality. After all, quality is a business decision.

This irresponsible action ends up causing organizations to be unpredictable in their delivery, have lower quality, and to burn out their teams. These outcomes in turn destroy brands, ruin company reputations on Wall Street, increase the percentage of each investor dollar serving up technical debt (in lieu of adding new value to products), and causes instability in the organization’s systems due to turnover.

Bottom line, if an organization can’t make the commitment to respect their product development system’s proven delivery capability at the current level, neither Kanban nor Scrum will provide predictability. But even in the face of this dysfunction, agile methodologies like Kanban and Scrum can still provide faster learning to teams, which allows them to test their assumptions faster and provide more value to their customers by delivering what they actually need.

In conclusion, I leave you with this advice: ignore the myths and hype about Kanban. Before you can make any decisions on the Kanban vs Scrum debate, you must first evaluate:

•Your organization’s product development and sales culture,

•The nature of the demand for service from product development,

•The competency of your organization to plan and execute change, and

•The degree to which you’re willing to face the truth

Only then can you choose the best agile software tool for the job.

A simple solution using OneNote

A page of a section of a notebook can be treated as Kanban board (e.g., you can create a dedicated page for each project iteration/phase. For each project you may create dedicated section).

It has several ways for sharing:

  1. Over filesystem (i.e., you may put notebook on shared folder within windows network). You can grant permission (full access\read only) as well
  2. Over TCP\IP ports in local networks.
  3. Over web. (OneNote 2010 is required)

There are several nice features also:

  1. drag & drop
  2. integration with outlook. you can easily send task to some of your teammate
  3. icons flavors for notes/task
  4. priorities & alarm

Sample image of the one of my project. Although it is not Kanban board, it is enough to demonstrate the idea.