Current Articles | RSS Feed RSS Feed

Kanban Metrics: Measure Cycle Time To Stay Lean

Posted by Titas Norkunas on Thu, Sep 26, 2013

Every Project Manager wants to reduce waste on their projects. The problem usually lies in detecting which parts of the process are ineffective. We are introducing the Cycle Time Report to help you deal with this exact issue.

cycle time report

End To End Lead Time

First of all, the End To End Lead Time is there to show you the overall pace of your team. It is the median time in which the ticket goes from being created to being closed. This includes all the steps in your process - analysis, planning, delivery, etc. This metric is great for strategic planning and the overall overview on the team's efficiency.

Delivery Lead Time

Delivery Lead Time helps you drill down to only the delivery step. You are doing analysis and planning while the ticket is in the Assembla Planners Backlog Milestone and moving it to Current Milestone when it is ready to be worked on. Delivery Lead Time will show you exactly how much time a ticket spends in your delivery pipeline. This metric (when compared to End To End Lead Time) will show you how effective you are at planning and analysis.

Cycle Time

Analyze the delivery step further with Cycle Time. This will eliminate all the waiting. In a pull system, tickets in status "New" are waiting until a developer picks it up and works on it. Cycle Time will show you how much time a ticket spends in every other status, waiting in "New" eliminated. This metric (when compared to Delivery Lead Time) will show you how much waiting you have in your Current pipeline and which steps on the process are the slowest.

For each of these metrics, we show the median value and the standard deviation. If your standard deviation is high, you can not trust the median. First step in optimizing your process will usually be making sure that you can get standard deviation as low as possible. Most common reason for this is tickets being too different in development effort needed. Try to break down bigger tasks into smaller ones.


What is the relative cost of a software bug fix? Some sources state up to 150-fold increases in costs of fixing bugs in latest steps of the pipeline. Time Cycle Report will show you the quality percentage in your tickets. 85% means, that 85 out of 100 of your tickets go through your pipeline without any hiccups - developers do not throw the issue back to analysis, Quality Assurance does not find bugs, etc. Any status regression in the ticket will decrease the quality. This is the best place to start with the Time Cycle Report.

Use Cases for the Time Cycle Report

This is far from everything an insightful manager will do with this report, but it might give you some ideas:

  • Reduce disruption that impacts efficiency, quality, and value - look at what parts of the process are slowest and ask yourself why that is

  • Create Service Level Agreements - agree with your team that tickets should be delivered on your prefered time scale and easily monitor your team's success

  • Continuously improve - track the overall Quality rating of your tickets. This is one of the easiest ways to ensure that you are improving

You can find the Time Cycle Report in the Metrics subtab of your Tickets Tool. Share the insights that you have got from the Time Cycle Report in the comments!

This report is available with the Renzoku feature pack. Subscribe for your free project here!

2 Comments Click here to read comments

Join the Continuous Revolution

Posted by Andy Singleton on Wed, Aug 21, 2013

We launched Assembla to work with distributed teams, and this required a new kind of agile dev process. Scrum with its stuffy meetings clearly did not fit the teams we work with. Cloud-based teams need to work differently.  We want to:

  • Release more frequently
  • Respond faster to users and customers
  • Scale to larger projects and teams
  • Manage distributed teams and tap global sources of talent
  • Compete better, especially with fast-cycle SaaS, Web, mobile, and big data projects
  • Reduce or eliminate the stress surrounding fixes and releases

The winner in this voyage of discovery is continuous planning and continuous delivery. The pace of competition on the Internet is so fast that all of the winners will eventually need to go continuous. In recent months we have talked to many companies that want to release more frequently, or continuously.

Continuous Agile combines traditional Kanban and Lean task management with recent innovations in Continuous Delivery.  It is is compatible with existing Scrum teams, but also works for modern, cloud-based teams and leading edge online services.

Our Continuous Agile initiative gathers together ideas, tools, and services to help you (and us) release more frequently and innovate faster. 

Ideas: Unblock! A Guide to the New Continuous Agile

Please check out an early draft of the ebook. We use this material to answer real questions from teams that are trying to release more frequently. We update it as we find new questions and ideas. You will find a VARIETY of approaches that you can use. We started building a guide that would cover basic task management, code contribution, and testing, so you would have a practical guide to the previously mysterious art of releasing every change. As we got into it, we found that some of the most interesting discoveries were around product management, which is the true route to success.

Co-authors contributed valuable knowledge. Michael Chletsos, Assembla CTO, contributed the big idea of “distributed” versus “centralized” flavors of CD.  He also put together the detailed workflows that allow us to release 250 times per month. Luca Milanesio sends us his innovations for building mobile apps. Damon Poole, now Chief Agilist at Eliassen and formerly the founder of Accurev, introduced me to Kanban and continuous release ideas three years ago, and is now figuring out how to apply them in large enterprises.

We’re moving some Continuous Agile ideas to We will expand our coverage of the big picture with more contributors and partners. will be more focused on the product with “what’s new” and “how to get more out of it” for users. So, add your bookmarks.

Tools: The Assembla Renzoku Release

The Renzoku package helps you plan, code, and release changes with one-piece-flow. It includes planning, Kanban view, code contribution, code review, and reporting. All of these activities are linked together on a ticket with a complete discussion and activity stream. Here’s an expanding list of relevant blog articles that describe the features. Please write in if you have questions about how to set up a continuous process.

Services: Hands-on Help

We’re expanding our “Release More Frequently” workshops, where we introduce your team to Continuous Agile, and help them figure out how to release more frequently.

Learn more at, and check back soon on this blog for announcements of public workshops online and in Boston.

0 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

New Ticket Metrics - Reports that are actually useful

Posted by Andy Singleton on Thu, Jan 10, 2013

The Tickets tool has an all new reporting UI.  You can find it under the Metrics subtab of the tickets tool.  This is a big leap forward for Assembla.  Our old reports (ticket metrics) were not useful, and we did not use them.  The new reports are redesigned to fit our continuous development process, so that every report has a purpose.

Please go and look at some of your reports, under Tickets/Metrics. You will probably learn something.  I did.  The first thing you will see is the “Contents” page.  This is a list of reports with a picture and an explanation of what the report  shows you.  Here are some new highlights:

Cumulative Flow Diagram

Cumulative Flow is so important that we will post a more complete article about it.  It shows you the status of open tickets, for each day that you have been working on the current milestone.  If you run a Scrum process, it will show you a burnup chart.  If you run a continuous or Kanban process, it will show your velocity, and what status tickets are piling up in.  Here is an article that shows the basic shape of Cumulative Flow.

Here a report for development.  You can see that we stopped doing releases during Christmas break, leading to a bulge in orange "Deploy now" status.

assembla cum flow resized 600


A simple way to see weekly velocity – by number of tickets, or by points.   Use this to see your ups and downs, and to estimate your future capacity.

Here is an Assembla velocity report. We use ticket count (every ticket is one point).  You can see a decline in closed tickets during Christmas week, and a half week (through Wednesday) at the end.

assembla velocity resized 600

Stuck Tickets

If you run a continuous process, you want to focus on tickets that do NOT move to the next step in a short period of time. Those are the things that will cause problems for your lean process.  The Stuck Tickets report shows them.  You enter a number of days, and it shows Current tickets that haven’t moved in that time.

These tickets have been stuck a long time!  I'm asking my guys to fix that.  I cut off the field at the end of the line that shows the date.  It sorts the oldest tickets to the top so you can see the biggest problems.

assembla stuck resized 600

BONUS – User reports

The user report has some nice new graphics.  This report is amazingly useful  for me.  It shows user activity across all Assembla tools.  You can link to it from the Tickets user report, which shows the tickets a user is working on, or from the “reports” link on the Team page.

The left panel shows the times that a user submitted events, in your time zone, or their time zone.  The right panel shows the type of things that they are working on.  The rest of the report shows everything that they are working on, in detail.

You can see that I now have a management job where I comment on tickets but don't post code commits or handle merge requests.  There's a lot more detail further down the report.

user report 3 resized 600


We have a lot of credits for these new features.  Hank Lander worked through the requirements.  Ryan Yeske came in and added sophisticated new data structures to track the cumulative flow.  Felipe Artur, Kivanio Barbosa, and Andres Aguilar implemented the reports.  Paco Lule made design improvements. Leandro Camargo brought all these pieces together to bring the reports to completion. 

Get all of these reports - and more - with Assembla Renzoku

3 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

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

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

FREE Planner for lightweight Agile, Scrum, and Kanban

Posted by Andy Singleton on Fri, Jun 29, 2012

When we first introduced the Agile Planner, you asked for a free version and we promised to deliver. Here it is, a free Agile Planner configuration.

Planner works with three columns on one page.  Use “New” to collect feature requests, tasks, and bug reports. Then, sort them into a prioritized “Backlog” so that you work on the most important stuff first. Then you move tasks to “Current” where you can assign tasks, discuss, share screenshots, and eventually move them “Closed” when a task is complete. Read these instructions to learn how to run an iterative (Scrum style) or continuous (Kanban style) project in just a few minutes.

planner view

Here is a video of me getting started:

Why are we offering a free Agile Planner?

We want to make your life easier by making our product simpler. The Agile Planner is simple, works immediately, and the free version has no configuration options. Is this a benefit or a bug? You decide. Personally, I have started using the Planner almost exclusively when organizing projects with partners.

This freemium offer is also a good way for us to find new customers for our oter tools. Many current customers found us through our simple/single/free Subversion and Git repository tools. Now we can help people get started with lightweight agile task management.  We can work with you to build distributed agile teams, and finally, run scalable agile development with multiple teams.

New features:

We recently released some new features, and many other upgrades are planned or in development. For example, we are testing a mobile app, and we are testing an all-new ticket layout that will provide all of today’s features in a more usable format.

How to get started:

Create a free Agile Planner configuration in seconds.  It's free for up to 4 users and unlimited tasks.  If you would like to try our advanced tools, click on the upgrade tab of the free space and upgrade to a 30-day trial.

2 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: