Current Articles | RSS Feed RSS Feed

"No Scrum" T-shirts for our visit to Agile 2013

Posted by Andy Singleton on Wed, Jul 31, 2013
Tags: ,

We printed up some "No Scrum" T-shirts for the Agile 2013 Conference.  The conference is mostly attended by Scrum coaches, so this should be a good conversation starter.  The back side promotes "Continuous Agile and Beyond Scrum Roadmap."  See you there.

IMG 1812 resized 600

1 Comments Click here to read comments

How to Manage Agile with Assembla: Tutorials

Posted by Jon Friedman on Wed, May 29, 2013

How do you plan, manage and close Scrum sprints with Assembla?

Stabilize a Scrumban iteration? (And what is "Scrumban"?)

Manage the tasks in a Kanban or lean Continuous Delivery process?

Assembla has very flexible tools for managing Agile (and non-Agile) development processes. So flexible, that it's not always obvious how to manage tasks for a specific Agile methodology.

That's why we have created three online tutorials that walk you through how to manage Scrum, Scrumban and Kanban processes using Assembla's new Renzoku feature set.

Tutorial screen

You can find the tutorials here:

How to Manage Scrum with Assembla

How to Manage Scrumban with Assembla

How to Manage Kanban/Continuous with Assembla

By the way, Scrumban uses periodic releases, like Scrum, but adopts some lean practices from Kanban. Read about it here.

3 Comments Click here to read comments

The Cumulative Flow Diagram: Your Most Valuable Management Report?

Posted by Jon Friedman on Wed, Feb 20, 2013

The Cumulative Flow Diagram (CFD) is an extremely valuable management report. It gives you an “at a glance” picture of key process variables such as velocity, WIP and ticket cycle times. It can help you release more features faster by identifying bottlenecks and problems in your development process.

In Assembla it takes less than a minute to generate a CFD with your own ticket data.

In this blog post we will show you how to create a CFD, measure velocity and find bottlenecks in your development process. In the next post we will discuss cycle times and how the CFD can warn you about scope creep and other process problems.

Generate Your CFD

Cumulative Flow Diagrams are one of the management reports available as part of the Assembla Tickets tool.

To create a Cumulative Flow Diagram based on your ticket activity, just 

  1. Click on the Tickets tab.
  2. Click on the Metrics subtab.
  3. On the list of reports, click on Cumulative Flow Diagram
  4. Select the Milestone, Start Date and End Date and click the Update button

How to generate a CFD


What is on This Graph?

You will see a graph that looks somewhat like the one below. It shows the number of tickets in each of you status categories, for the milestone and the time period you have selected. 

If you draw a horizontal line at any point on this graph you will see a snapshot of your tickets on a given date (how many with status “New,” “In-Progress,” “Test,” etc.). In fact, if you move your cursor along the top boundary of any layer a popup box will list the number of tickets in that category on each date.

So the CFD is really just a picture of your tickets by status over time. But this picture can tell you a lot about your development process. 

Example of a CFD

Note: In your graph the shape of the layers may differ from Figure 1 depending on whether your development process is based on iterations and sprints, or on a continuous flow. You can see “ideal” Cumulative Flow Diagrams for Scrum, ScrumBan and Kanban processes in Andy Singleton’s blog post: Scrum + Kanban = ScrumBan, an Easy Scrum Upgrade.


The Departure Rate (Velocity) Helps You Project Completion

The bottom layer on the graph (usually labeled “Fixed,” or “Done” or “Completed”) shows the number of finished tickets at different times. The upper boundary shows the cumulative number of tickets completed or “burned up” in the iteration or milestone. 

The slope of this line is the “departure rate”; that is, the average number of tickets completed per time period. In Kanban and other flow process this is usually called the “velocity” (in this diagram measured in tickets completed rather than points).  Either way, it is a measure of throughput and productivity.

The departure rate can help you estimate:

  • The time needed to complete the current milestone.
  • The time and resources needed to complete future projects with a given number of tickets.

Of course, these estimates are not going to be exact, because different tickets require different amounts of work. But over time they should average out and let you make rough projections. (Also, if you have a few very large tickets you should try to find ways to break them up into smaller ones.)

In addition, changes in the departure rate might indicate problems with your development process. For example, in diagram below, why were so few tickets completed between 2012/11/12 and 2012/11/26? There might be a good reason, but the CFD clues you in on where to look for possible issues.

By the way, the upper boundary of the top layer on the CFD represents new tickets arriving into the milestone, so the slope of that line is the “arrival rate.” 

departure and arrival rates


WIP Levels Show You Bottlenecks

Identifying and eliminating process bottlenecks is a critical element of continuous improvement.

In the diagram below, the red vertical line represents work in process: the cumulative number of tickets accepted into the process but not yet completed. 

This information is useful because you can see how much work needs to be done at each level; for example how many tickets haven’t been started, how many are in progress, how many need to be tested, etc.

But even more important, you can see where your process developed bottlenecks. Those are at the places where a “boa constrictor” suddenly becomes fat. For example, in this diagram the “Deploy” layer goes from very thin to very thick between 12/11/26 and about 2012/12/07. It looks like something went wrong during this period and the imbalance in the process was only gradually worked out towards the end of the diagram.

View WIP and spot bottlenecks

Note that the cause of the problem may well be in the process step below the thick layer. In this diagram the bottleneck in the “Deploy” layer might have been caused by problems preparing new features for deployment, or by a constraint on actually deploying them and accepting them as “Fixed.” (If you “push” tickets, then the problem is likely to be in the fat layer; if you have a “pull” system it is probably in the lower or receiving layer).

The CFD makes it much easier to see when and where the bottlenecks started, so you can investigate the root causes and fix the underlying problems. 

In our next post we will look at cycle times and how to the CFD can help identify scope creep.

3 Comments Click here to read comments

Perforce Endorses "Beyond Scrum"

Posted by Jon Friedman on Thu, Jan 17, 2013

At Assembla, we have been working on going "Beyond Scrum" with new techniques for continuous delivery and scaling an agile project.  Our friends and technology partners at Perforce Software have joined the movement with a newsletter article: Beyond Scrum: How to Apply Agile Techniques to Distributed Teams and Large Projects.  This is the beginning of a tipping point in enterprise adoption.

Perforce built their presentation around one of our diagrams:

Perforce blog post Beyond Scrum


There is a lot of great material in this article. Much of it came from a joint webinar presented by Andy Singleton of Assembla and Randy DeFauw of Perforce. So take a look at the article, and if you want more detail watch the webinar too.

0 Comments Click here to read comments

How 11 Companies are Scaling Agile

Posted by Jon Friedman on Tue, Jan 08, 2013

The Scalable Agile Design Group (SADG) is an informal group representing 11 companies plus Assembla, pulled together to share ideas about how Agile techniques can be scaled up to address large, complex software development projects.

Although the group is not a scientific sample, it does contain a cross-section of midsized and large companies in businesses ranging from sporting goods, to financial services, to online computer games, to custom software development.

Below are findings that provide insight into how Agile is currently being used and where it is going, based on interviews and discussions with 11 companies that have scaled Agile to larger projects. We also include links to some recent Assembla blog posts related to these findings.

Finding #1: There are three distinct Agile use cases

There is not one set of Agile best practices that fits all development organizations. In fact, our group showed three use cases that dictate very different priorities and methods. Development teams fell into three categories:

  • “Major Release Developers” work on client-server and locally installed products with releases every three to six months
  • “Cloud Application Developers” build web-based applications that are updated frequently, as much as several times per day.
  • “Multi-Project Developers” work on many concurrent projects for multiple customers

The group you belong to determines which Agile practices make sense for you and which don’t.

Get more details in: The Three Agile Use Cases: Where Do You Fit In?

Finding #2: Almost no large Agile organization is totally co-located

The vast majority of companies in the group have distributed development organizations:

Number of companies with development staff in:

  • 7+ locations: 27%
  • 3-5 locations: 55%
  • 1 location: 18%

And almost all of these companies also have employees working at home, freelancers, and virtual business partners at multiple locations.

Finding #3: Scrum is the default Agile methodology

Scrum is clearly the predominant Agile methodology in the group.

Number of companies using:

  • Exclusively Scrum or “scrumish” techniques: 55%
  • Scrum and Kanban or Lean techniques: 36%
  • Exclusively Kanban or Lean techniques: 9%

Finding #4: Kanban has its place, but not as a replacement for Scrum

Kanban is not seen as a new wave replacing Scrum. Rather, Kanban and lean techniques are seen as the right fit for web-based applications with frequent releases (Cloud app developers in finding #1), while Scrum is still viewed as optimal for client-server and locally installed applications with less frequent releases.

Finding #5: Teams are adding lean concepts to sprints (ScrumBan)

Companies are incorporating Lean concepts into their Scrum processes. This includes leaving room in the sprint plan for last-minute new tasks and limiting WIP within a sprint. These practices reduce some of the inflexibility of pure Scrum, while preserving advantages such as having defined releases at regular intervals.

We recently posted a blog article that discusses this hybrid approach. Check out: Scrum + Kanban = ScrumBan, an Easy Scrum Upgrade. See where ScrumBan fits in the progression toward Continuous Delivery: Assembla's Beyond Scrum Roadmap

Finding #6: Coordinating teams and dependencies is a major challenge for scaling Agile

Perhaps the greatest challenge in scaling up Agile projects is coordinating teams and managing dependencies across teams. As projects grow, development groups resort to ever more complicated and time-consuming rounds of meetings and calls. This is clearly a topic crying out for new ideas and fresh thinking.

Read: 3 Ways to Handle Dependencies

Finding #7: Continuous Integration and integrated testing are critical for scaling

The companies that have scaled most successfully are strong believers in Continuous Integration. They have invested in processes and automated build tools to the point where they create new builds daily or several times each day.

The organizations with the fastest release cycles have also worked hard on integrating testing into all parts of the development cycle. Testing early and often allows them to find and fix problems faster, without slowing down release cycles.

Assembla has published a lot about continuous integration and Continuous Delivery: 

Do these findings ring true for you?

Do these findings agree with your experiences, or contradict them? Please comment below.

0 Comments Click here to read comments

Story tickets with subtasks / to-do lists

Posted by Andy Singleton on Fri, Jan 04, 2013

We just released a frequently requested feature - an implementation of Story tickets with subtasks. You can use the subtasks in a Scrum planning process, or you can use them as an informal to-do list. To see this new feature, go to the Tickets/Planner UI, and open a ticket by selecting the little triangle on the side. This opens a “task tray” under the ticket. You can write into the form to make a list of subtasks. You can create a to-do list in a few seconds, right there in the task tray. You can also drop other tickets into the task tray.

task tray resized 600

Tasks move with the parent Story ticket. So, if you sort the Story, or move it to the Current column, or to a different milestone, the tasks go with it. Use this relationship to make a list of tasks that should be completed before you release the parent Story.

You can also see the Tasks on the “Related Tickets” tab of the parent Story ticket, and you can add or edit tasks right inside the Story ticket.

related tickets resized 600

The tasks are complete tickets, so you can assign them, discuss them, and see them in Cardwall and List views.

list view resized 600

In the old Outline view, parent and child tickets are only loosely related, and child tickets do not move with the parent. The Outline parent tickets create an “epic” relationship, where you can release each tasks separately on the way to completing a major feature. We’re going to remove the old Outline UI in favor of the more modern Planner, but will offer a way to build the Epic relationships. Many Outline users told us that they wanted “move with the parent” behavior. So, now you have it with the expanding tasks on the Planner. Please switch over to the Planner UI.

Here are two ideas for using Stories and Tasks:

1) You can use Stories and Tasks in a classic Scrum planning process where you write Story tickets, and put them in your backlog, without tasks. The Story ticket describes the function, not the implementation. It includes a summary of the user goal and functional requirements, for example “I am a user and I want X, so I use the system do this action…” Then, after you pull a ticket over to the Current work column, you expand it by adding more detailed implementation tasks. Then you finish all of the tasks, and close the parent Story.

2) You can use this to make your backlog smaller and easier to handle by grouping several backlog tasks together under one functional story. You can drag and drop tickets into the story tray under a parent ticket. The Tasks are hidden in the Planner view, but are still fully functional tickets in the other views.

We thank André Mendonça for implementing this feature - get it for free with Assembla Renzoku!

33 Comments Click here to read comments

The Three Agile Use Cases: Where Do You Fit In?

Posted by Jon Friedman on Tue, Oct 23, 2012

There are three distinct “use cases” for employing Agile techniques. They are based on different business challenges. They should be addressed by different Agile processes. If you don’t know which one you are, you are probably doing it wrong.

The three use cases are:

  • Long release cycles of 3, 6, or 12 months
  • Online apps (Web, SaaS, enterprise cloud, big data, centrally deployed)
  • Developers servicing multiple clients or projects


Earlier this year Assembla formed the “Scalable Agile Design Group,” a collection of senior managers of development groups at 12 companies with extensive Agile experience. We created the group to learn more about the common issues facing Agile companies.

We were surprised to find that there is no one common set of issues. We found three distinct types of Agile companies. Each has a different set of pain points and priorities. Each focuses on different processes and tools to address those priorities. They were almost talking different languages.

The conclusion: knowing your use case will tell you what parts of Agile to emphasize and what parts to ignore.

Major Release Developers

“Major Release Developers” are development organizations that work on long-term projects, typically with release dates three or more months apart. Often they are building classic “enterprise” applications. Teams are usually assigned to one project for months, or even years.

These organizations can reap gains by using classic Agile techniques like sprints, scrum masters and product owners who provide customer input on a daily basis. They make extensive use of Agile training and Agile coaches to inculcate Agile principles and improve coherence within teams. Essentially they are focused on maximizing team efficiency across long-term projects that do not deal with frequently changing requirements, bug fixes, etc.

Most Agile textbooks are written for this use case.

So doesn’t this reflect almost all Agile development groups? No, not at all.

Cloud Application Developers

“Cloud Application Developers” maintain web- and cloud-based applications, and release new functionality frequently. They include organizations supporting web sites and web-based applications within an enterprise, SaaS companies, and major “cloud” services providers like SalesForce or Google.

These companies are driven to:

  • Release new functionality frequently, sometimes several times each day.
  • Reduce cycle times, to react quickly to customer and marketplace feedback.
  • Automate processes to reduce the burden of frequent releases.

Scrum is actually a bad model for these companies. It prevents them from releasing any more frequently than the end of each sprint (typically every 2-6 weeks). They can’t easily handle tasks introduced in the middle of sprints, no matter how high the priority. And they create a lot of overhead with planning meetings, scrum-of-scrum meetings and retrospectives.

Instead, these companies gain the most by emphasizing:

  • Kanban and lean techniques.
  • Continuous integration, including automated builds and automated tests, and continuous delivery. 
  • Collaboration tools for distributed teams, to take advantage of the global market for development talent.

Multi-Project Developers

“Multi-Project Developers” is the third use case. These groups work on many concurrent projects and move teams among them. Many are service providers and custom development shops, but they also include IT groups that service multiple business units inside an enterprise.

Because these organizations are constantly moving teams around and reconfiguring them, Scrum doesn’t buy them much. 

Their challenges revolve around resource management. They need to pay close attention to capacity planning and resource allocation across projects (especially for people with scarce skills). They benefit from frequent, low-friction communication with client organizations. They also need to onboard new developers easily.

The tools to address these challenges include ticketing and planning systems, collaboration tools, and tools that allow customers to provide rapid feedback and track the progress of their projects.

Some Have Two

We found several Scalable Agile Design Group members that had more than one use case within their company.

For example, part of the organization might be working on an enterprise accounting application (the Major Release Developer use case), while another part is working on web sites or data warehousing projects that need to make changes on a daily basis (the Cloud Application Developer use case). 

These companies found, sometimes to their surprise, that Scrum teams would take root in the first area, while Lean techniques thrived in the second.

What Does This Mean to Me?

If your group fits the Major Release Developer use case then you are probably in good shape staying with the classic Agile textbooks.

But if you are a Cloud Application Developer or a Multi-Project Developer wondering why Scrum hasn’t brought you very far, then you should look at some of our blog posts about Going Beyond ScrumContinuous Delivery, and Scalable Agile

0 Comments Click here to read comments

Beyond Scrum Roadmap

Posted by Andy Singleton on Wed, Oct 17, 2012

About six months ago, we started working internally on our "beyond Scrum" campaign to improve agile software development so that it works in a cloud-based world. As noted in my article, 7 Things I Hate About Agile, I don’t agree with Scrum, the dominant agile methodology.  I was called everything from "ignorant youngster" to “bitter old man” to a “Moron with a capital M.” However, the response was big.  50,000 people read the article. 1200 signed up for a “Beyond Scrum” webinar that we did with Perforce. It’s clear that a lot of people are ready to move on to the next step.

Here is our roadmap for the positive steps beyond Scrum.

Beyond Scrum Chart 3

In moving our own teams and development process along this path, we were to increase our release frequency from twice a month to almost 60 releases in September - all while fixing issues faster, releasing more features, and overall happier team members. It worked!

Let’s look at this roadmap in more detail.

Distributed Teams and Scrumban


Because modern software teams really are distributed around the world. Once you accept that fact, your project will run much more smoothly at any scale bigger than one person, and you will find the people you need.

A simple first step is a Scrumban process that works with co-located and distributed teams. Scrumban will save you precious time by removing upfront release planning and allow your sprints to be more flexible for bugs/issues, chaging requirements, new features, etc.

Key Principles

  • People work where they are, which is usually distributed
  • Unite the team with strong social features and activity stream
  • Tasks and code are shared online
  • Team members pull one task at a time.  Manage WIP (work in process)
  • At the end of the iteration, freeze new tasks and stabilize what is ready
  • Release on schedule

Assembla Product Features

This could be a really long list. Assembla Workspaces was designed to support distributed teams. Workspaces provide a place to create, plan, and manage tasks, share code (Subversion and Git and Perforce), and collaborate on project specs/requirements. We find that a key driver of team performance is the activity stream, which allows you to see what other team members are doing, and we have enhanced this with popular social features like @mentions.

Continuous Delivery


Continuous delivery is the art of releasing software whenever you have a valid change, often many times per day.  It’s a natural goal for online services that are centrally deployed and updated. If your product gets released less frequently, you can still run continuous delivery in the development group.

1) It's hot

2) Moving to multiple releases per day resulted in big improvements for us, and we’d like to help more people get the same benefits. It dramatically reduces release planning and release related stress. You can do more because each task takes the right amount of time. It simplifies the interactions between teams and team members. And, it’s faster. If your competitor is running continuous delivery, you will eventually have to do it, or be overrun.  It also helps with scaling, since it removes the big meetings for iteration and release planning.  As we hear more about what is happening in Silicon Valley, we are becoming convinced that continuous delivery might be the only effective way to organize a big agile effort.

When I first heard about , I thought it was crazy, assuming that every release of a serious product needs testing phase.  When we started studying it, we found a few specific tactics that will move any project to continuous delivery.

Key Principles

  • Multiple test environments, on-demand, or one for each contributor or contributing team
  • Continuous integration with automated tests
  • On-demand test and stage environments
  • Code review to enforce test coverage and other requirements
  • Accept and merge changes when they are ready
  • Release on-demand, whever you want. Alternatively, deliver to batch testing “when ready”

Assembla Product Features

Continuous delivery requires code-related features to support multiple test environments, like the merge request workflow, various types of continuous integration, and the new SSH build tool. It also requires a new Kanban style approach to task management. We’ve redesigned our ticket workflow to fit.

  • Agile Planner and virtual Cardwall 
  • Merge requests with code review
  • Cumulative flow diagram and other metrics to measure velocity and throughput
  • SSH build tool
  • Jenkins integration

(Get these features for free with Assembla Renzoku)

We have also fired up some services that are not related to the product.  We are working with customers that need help with consulting and continuous integration, build and test scripts, and other DevOps stuff.  We hope that we can help them get to the next step with whatever tools and process they already have.



Scaling to get more development done, faster, with bigger teams, is the most expensive problem in software.  We can use Internet technology to make it less expensive and much less painful. We have found tactics for working with globally distributed teams, breaking one backlog down into multiple teams, and adding and evaluating teams.  We can help them work together by removing the big meetings for iteration planning, dependency planning, and release planning so each team can work at full velocity on its own schedule. If necessary, you can go big – big like projects we studied at Facebook and Google Android.  At smaller scale we can use the same simple mechanisms to scale up AND make projects more agile.

Key Principles

  • Eliminate batch processes and big meetings
  • Add people or complete teams
  • Distribute tasks from a shared backlog
  • Evaluate and report on contributors

Assembla Product Features

We built Assembla Portfolio specifically for companies that want to scale and make large projects more agile, and we are making major enhancements to it.

  • Multi-team topologies so multiple teams can work on a project
  • Large backlog management
  • Fork and merge
  • User reports and team activity reports
  • Portfolio (roll-up) reports
Get Assembla Portfolio for your spaces starting at $79 here.

2 Comments Click here to read comments

Beyond Scrum: Introducing Simple Scalable Agile Development [Video]

Posted by Jon Friedman on Thu, Sep 27, 2012

On 9/25/2012, Assembla and Perforce presented a webinar titled "Beyond Scrum: Introducing Simple Scalable Agile Development." It is very clear that this is a hot topic with over 1,000 people registering for the webinar. For those that did not get a chance to register or attend, the video and slides are below. Enjoy. 

 View and download the slides.

Webinar Overview:

Scrum is the most popular Agile process, and aspects like the daily meeting are familiar to most developers and businesspeople. But it's not for everyone.

Scrum was designed for small collocated teams working on simple projects. Larger Scrum projects can experience hierarchical planning, integration nightmares, and inefficient use of resources.

In this webinar you'll see an Agile framework that avoids these problems by recognizing the concept that managing code is often easier than managing people.

Other Releated Resources from our Blog:

0 Comments Click here to read comments

Scrum + Kanban = ScrumBan, an Easy Scrum Upgrade

Posted by Andy Singleton on Tue, Aug 28, 2012

These simple charts show how we can combine Scrum (with periodic releases) and Kanban (with very frequent releases) and combine them in a “ScrumBan” process that has periodic releases, and is an improvement on the normal Scrum process.  It's better for distributed teams, and closer to the way many of them actually work now.  It's a simple step toward the fully scalable process that we will propose later.


Here’s what a Scrum process looks like in a “continuous flow diagram:”

idealized scrum

You select your current work as a “Sprint backlog.”  Then, you burn up the completed  tasks until (hopefully) you are ready to release.

In actuality, you don’t usually see sprints that match this chart.  Tasks get added near the beginning, and removed near the end.  You can get a lot of bottlenecks when you get near the end of a release.


In a Kanban process, you select a list of "Work In Progress (WIP)."  As you finish one task from this list, you select a new task.  This continues without stopping at special release points.

idealize kanban

Note that WIP in a Kanban process is usually not expressed in terms of size or points.  This is because Kanban uses a “lean” philosophy, where the idea is to avoid having tasks that are waiting around for someone to work on them. Kanban limits the number of tasks, regardless of size, so that each current task has someone that is working on it.  A task that will take 1 day and a task that takes 9 days require the same amount of attention today.  In contrast, a Scrum team will consider a task that takes 9 days to be similar in size to 9 tasks that take one day, sequentially.  The Kanban WIP limit is a simple and effective way to ensure that each current task is finished as rapidly as possible, it doesn’t require estimating, and it provides a natural way to work on tasks that take longer than one iteration.

The Kanban process has a lot of advantages, and it is great if you update an online service with daily releases.  However, most teams can’t release every day.  They send things to the appstore once per month, or have enterprise clients that will accept quarterly updates, or burn CD’s or PROMS every year.  They need periodic releases that are stable.  For those teams, we suggest the ScrumBan process.


In our idealized ScrumBan process, you start your sprint with the normal Kanban process.  When you get closer to the end of the sprint, you do some things to get ready for a release which I have labeled here with my own vocabulary.

idealized scrumban

Triage:  Find tasks that you are not going to finish by release time, and get rid of them by moving them to a future release.  This is actually an important part of any process that delivers releases at a fixed time.  I have diagrammed all of the triage at one time, but  you should  actually do it whenever you find a task that is not likely to be  completed in time.

Feature Freeze: Stop adding new tasks to the list of current work.  Then, you  can stabilize your release by burning down the list of incomplete tasks and problems (shown here as burning up the closed tasks).

Stabilization: Finish or remove tasks, and fix problems, until you have a stable release.  The cumulative flow diagram converges to the end of the iteration, One hint for the stabilization phase is to not allow developers to move on to new tasks until the release is finished.  This creates psychological pressure to finish a good release.

I find that the stabilization process often takes about 1/3 of the release cycle.  A good rule of thumb for your first release cycle is to do an aggressive triage and  a feature freeze by the  time  you have used up 2/3 of your  time to release.  If you can stabilize in a shorter time, you might be ready for a straight Kanban process, using this testing secret.

If you are using Scrum sprints, I recommend that you try this Scrumban process for your next sprint.   You get two immediate advantages:

1) You don’t have to do estimating and sprint planning.  Hooray!  You get an extra day for design and programming.  If you have one or more distributed teams (like the Constant Contact project shown below), you avoid the logistical challenges of agreeing on a sprint plan.

2) You can add bug fixes at any time.  In the idealized Scrum process, it’s annoying how bug fixes go into a separate work queue.

Compare the ideal Scrumban diagram to this real continuous flow diagram presented by Gil Irrizarry of Constant Contact.

constant contact diagramGet Cumulative Chart Diagram and Cardwall to help you out with ScrumBan for free with Assembla Renzoku.

4 Comments Click here to read comments

All Posts | Next Page

Follow Assembla

twitter facebook youtube linkedin googleplus

Get Started

blog CTA button

Subscribe by Email

Your email: