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.

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.

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

 

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. 

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.” 

 

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.

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.

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:

 

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.

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 Assembla.com development.  You can see that we stopped doing releases during Christmas break, leading to a bulge in orange "Deploy now" status.

Velocity

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.

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.

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.

 

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. 

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: 

• Continuous Delivery and Scalable Agile - Find Out the Secret
• Continuous Delivery vs Continuous Deployment vs Continuous Integration
• How we learned to stop worrying and ship software every day
• Take Control with the Continuous Delivery Dial
• Assembla Tools for Continuous Delivery

Do these findings ring true for you?

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

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

Background

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 Scrum, Continuous Delivery, and Scalable Agile. 

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.

Scrum

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

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.

Kanban

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.

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.

ScrumBan

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.

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.

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

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.

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.

Today you will see a new tab called "Planner" on the left side of your Tickets tool.  Planner will make it easier for you to start new projects and to run agile projects.

Assembla Tickets is powerful and flexible, but it can be daunting to use if you are just starting out. There are many ways to configure milestones and ticket lists and custom fields and status values to fit a customized process.  Most users just want to get started quickly with a process that already works.

Simple Planner is the solution.  It's implemented on one page with popup details.

Sort Differently

Simple Planner is compatible with existing tickets and milestones.  You can view your existing tickets in the Planner or start in the Planner and switch to the cardwall or a customized list view.

There is a difference in how Planner organizes tickets.  If you are a current user of Assembla tickets, you probably sort tasks using milestones and priority.  You lay out your roadmap with sequential milestones.  Some customers use milestones as containers for other things such as clients or products.  Inside a milestone, you mark a ticket with Priority.  If you mark a ticket as "Highest" priority, it floats to the top in all of our default views and gets a bright color.  Setting a priority is a fast way to sort, which is why I created this implementation.

Planner replaces the two ideas of milestone and priority with one concept: sorting.  Tickets go into one backlog milestone, and you drag-and-drop to sort them.  They stay in place even if you change the priority.  This sorting process gives you more precise control over the list of tasks and it is easier to set up.

Instructions

Is it simple?  Here on one page are the complete instructions for using Simple Planner, including for Scrum and Kanban.

To start using the Planner

You and your team members will enter tickets as “New”.  A product owner or tech lead will move New tickets to Backlog and sort them.  The owner can also drag tickets directly to Current.  Team members will work on the Current tickets.

The New ticket form only asks for a title and a description.  If you want to enter more fields in the ticket, you can use Settings to set default values, or you can click through to the “Advanced” form which has room for more fields and file attachments.

Click on a ticket card to see the description, attachments, and comments.  Many teams will add comments to discuss the task and read email alerts to see the discussion.

Connect a task with a user by selecting a team member in the assigned to field.  They will see the ticket in their list of followed tickets, and you will see their pictures on the tickets.  Click the star to follow a ticket (you will get emails about comments and status changes) or un-follow a ticket.  Use the status field to move tickets to a new status, eventually moving them to "Fixed" or Closed status. You can use the context menu (shown below) to make updates to a ticket quickly. 

Current and Backlog milestones

The Planner uses three milestones:

New - Not assigned to a milestone.  This container gives you an efficient way to collect requests, suggestions, and bug reports.  They go into the New container, and later, a product owner or tech lead sorts them by priority.

Backlog - This contains a list of all the things that you want to do, sorted in priority order.

Current - This contains the list of tasks that your team is working on now.  You an edit this list every day, or you can run an iterative process where you load the Current list, and then "burn down" until you finish all tasks.  Current tasks also appear on the Cardwall, burndown, and other views.

If you have an existing project, and you go to the Planner subtab, the Planner will ask you to select Current and Backlog milestones from your existing list of milestones, or create new milestones, which it will name "Current" and "Backlog".

To sort your tasks

Make a plan by sorting the Backlog list of tasks into the order that you want to work on them.  Move urgent tasks to the top.  Move tickets from the top of Backlog to Current with the "Load" button, or by dragging them manually.

The simplest way to sort is to use the arrow icons for “Send to top” – send a ticket that you want to work on now to the top of the Backlog, and “Send to bottom” – send a ticket that you do not want to work on now to the bottom of the backlog.  You will see these icons in the New and Backlog columns.  You can also sort with drag and drop.

To manage a Kanban process

Enter a capacity on top of the Current column.  Capacity is the number of points that you want to see on your Kanban board.  Add estimates to tickets.  Select “Load” to move tickets into Current.  Do this frequently so that you always have approximately the right number of Current tickets.  You will see your current tickets on the Cardwall in a traditional Kanban board view.

With a Kanban or lean process, you want to control the number of tasks (WIP or Work In Progress) so that someone is working on each task, and no task is just waiting.  This simple tactic allows you to deliver each task as quickly as possible, which is efficient, and very satisfying.  You can ensure that each task is being worked on by controlling the number of tickets, not the size of the tickets. We often recommend an estimate setting of  "Do not estimate" (which will load ticket counts and not points), and a capacity that allows one, two, or three tickets per team member.

To manage a Scrum or iterative process

To start a sprint - Enter a capacity.  Select “Load” to move tickets into Current and start your iteration.  

To finish a sprint - "Show closed tickets"  in the Current column.  You will see all of the closed tickets in the Current milestone.  Select “Close Iteration”.  This will close and rename the Current milestone.  Give this old milestone a name that describes your sprint or release.  It will create a new Current milestone, and move any open tickets to that new Current milestone.

With a scrum or iterative process, you will want to estimate the total amount of work that you can do in an iteration.  Use Small/Medium/Large or integer points.

Estimate types

A project owner can select several estimate types on the Settings page (shown above).  

• "Do not estimate" will hide the estimates and set every ticket to 1 point.  So, the Capacity measures will equal ticket counts, which is useful for a Lean methodology.
• "Small / Medium / Large" gives you a popup widget for estimating “Small” (1 point), “Medium” (3 points), or “Large” (7 points).
• "Points" gives you an integer field for entering estimates.

We match these points with a “Capacity” – the approximate number of points that your team can work on at one time.  If you do not enter a capacity, and you do some work, then we will calculate capacity from historical velocity – the number of points in tickets that are closed in the last week.

Estimates do not need to be accurate.  Even simple estimates will help you work on approximately the right number of tickets.  It is more important to sort your tasks in priority order.  If your tickets are sorted correctly, you will always be working on the most important tasks.

Switch Views

Switch to the Cardwall view to see your Current tasks in a Scrum Board or Kanban Board format.

What do you think of the new Simple Planner? Get it for free with Assembla Renzoku. 

Here are answers to questions posed during the lively question and answer period of the webinar Scrum, Kanban and Scalable Agile, in no special order.

Here is a video recording of the webinar. 

Q: Is the cardwall (Assembla) view the same as kanban?

A: Kanban is a work process that involves trying to move a task as quickly as possible through various stages, for example, design, development and test.  The “Kanban board” is a bulletin board where you can see tasks represented as cards in status columns.  “Kanban” is Japanese for, approximately, “card display.” The Assembla cardwall is a view of Assembla tickets, represented as cards, arranged into columns for each status.  You can use it as a Kanban board or Scrum board.

Q: Are pull requests part of the "Issue Tracking/Ticketing" feature?

A: Merge Requests are part of the git repository feature (Source/git tool  in Assembla).

Q: When will the backlog planner be available in production?

A: The Simple Planner will be available in about four weeks – the second week in April.  We will need  another three weeks after that to finish Backlog planner. 

Q: When will the features Andy demonstrated be made available to Private Install users?

A: Advanced merge request will be available in the Private Install the first week in April.  Simple Planner will be available by the end of April. For those who haven’t heard about it before, Private Install is a version of Assembla that can be installed in your data center.

Q: is it possible to have a "standard" milestone, with x amount of tickets, if you have a standard flow you use several times a year?

A: We have received this request before.  I think that the idea is to basically copy a template milestone, so that you get a prepared list of tasks.  There is no simple way to do this now in the Assembla Tickets feature.  We will add a cut and paste feature that will make this easier.  In the current system, you can make a project Space that contains prepared milestones and tickets, and copy that.  You can do it with the “template” type in a portfolio, or with “Copy this space” in the footer of any space.

Q: Andy, what was the development language in the project you mentioned?

A: We mentioned the Assembla.com development project.  We use Ruby on Rails, combined with various other components (message queue, hacks for git and subversion, etc.)

Q: Are there any plans to release an aggregated planner for Assembla Portfolio?

A: Yes.  This is an important design project.  We call it the “Multi-team” dashboard, because it will help many teams work on one project.  I am going to invite people to join us in this design process, and I hope this will also be a forum where people can share ideas about Scalable Agile.  If you are interested, please email us at scalable_agile (at) assembla.com.

A: At the code level, I think that you just have to distribute all of the code, and let each person work on his piece.  They will be building the same code, but independently.  Sharing is scaling.  If you share the code, people can figure out for themselves how to fix problems or get in touch with other component specialist, and route around problems.  At the level of a cloud system, you often have separate servers.  Then you have a more complicated job if you want to give people a place to test their stuff with everyone else’s components.   I personally think that the miracle of on-demand cloud systems often makes it possible to give each feature team a sandbox with many of the components.  They should be as independently powerful as possible, to remove constraints.

In both cases, I like the idea that each developer or team is going to pull changes from the current release, and test the current release with their changes.  This is in contrast to a system where they all push changes to a central build.  You can often block people if they are waiting for centralized test resources.

Q: In Assembla workflow, is it possible to manage teams backlog?   There is the global project backlog feature, but what about if you have specialized teams and want to assign a specific ticket to a specific team?

A: In the Assembla.com development project we added a custom field for “Feature team” so that we can assign a ticket to a team, and we can use filters to see tickets for a team in the List or Cardwall views.  We are going to carry this idea into the Backlog sorter, where you will be able to select the same filtered  view (for example, just team X) and sort that smaller list.

Q: Will Assembla support pure Scrum in the near future? If not, why not? :)  Why are there story points for subtasks – do these make the burn-down inaccurate? Regarding the average velocity calculation / chart – are there any plans to add that to Assembla in the near future?

I believe that the most important think that Scrum teams use that Assembla lacks is the Story/subtask breakdown. We support this in the “Outline” view, and with child tasks, but not in the other views.  We will add this to the Simple Planner in a second release, so that you can plan with stories, and then expand them with a list of subtasks when they move into the Current work bin.

We let you enter points on stories or subtasks.   You will need a policy to use one or the other, because they will add together.   If your policy is to enter zero points on subtasks, then your story estimate will be useful.

Yes, the Simple planner will include an average velocity calculation and chart, with the four week trailing average used  to set the capacity default.  With these adjustments, Simple Planner will match the traditional Scrum process.

Q: Any plans for plugins for IDEs such as VS, Netbeans, Eclipse, etc?  

A: Assembla has a MyLyn plugin for Eclipse that is actively maintained by a contributor named Brett Smith.  Thanks, Brett.  We do not have any plans to support Netbeans and Visual Studio, but we will work with and subsidize contributors who want to work on those.

Q:  What kind of predictability do you have around when a feature will be released? 

With our process, I find that I can predict about six weeks in advance.  So, the release date is fuzzy until we are within six weeks of release.  I hypothesize that you can increase this time horizon if you work on bigger features, and if you have slack  or are not going as fast as possible.   There is obviously a direct tradeoff between how hard you are driving and how much predictability you get, and I am willing to trade away predictability and just focus on top priorities.  There are people who are much better at tracking velocity and improving estimates.  Those people will have a useful tool in the Simple Planner.  It encourages you to enter an estimate in points on every ticket, it tracks historical velocity, and it uses that to put bars into the sorted backlog that show the estimated release date at various points down the backlog.

Q: About scaling for multiple teams. How does the new planner support multiple team development? We use one backlog, but we need to follow-up each team’s contribution during a Sprint.

I have three suggestions for you.  First, we are using YOUR idea of feature teams as a filter, and giving you a way to filter the backlog sorter and cardwall view for each team in a space.  Second, the Advanced Merge Request will help you merge code from different teams.  Third, we are building a new “Multi-team” planner in the Portfolio.  This has four basic functions.  It helps you set a milestone for all of the related spaces/teams working on a project.  It reports on all of the tasks in that milestone.  It helps you move tasks between the spaces for different teams.  It will show dependency relationships between tasks, and between tasks for different teams, so that you can see, for example, if one team is waiting for something that is not in the Current iteration for a different team.  I want to involve you in the design process for this feature.

A: Git does require some training.  It has more commands and is conceptually different from Subversion.  We recently posted a tutorial about setting up git for Windows – a common question.  I will look for a more comprehensive list of tutorials.

Q: When will Assembla support enforced/defined WIP limits?

A: In the Simple Planner we give you a convenient place to estimate work amount (a prerequisite for WIP limits) and we enforce a WIP limit for the Current iteration or bin.  As soon as that is released we will add capacity settings to the cardwall columns (status values).  This  will not enforce a limit, but it will show an alert on the column when you are over the limit.

Q: In the examples you have shown, stories do not split into tasks. Would not be easier to maintain a product backlog with higher level stories, which are divided into tasks when enter into production?

A: Yes.  That will be in a second release.

Q: Has Agile or Kanban helped you deal with developers incorrectly trying to fulfill their role rather than trying to help the product?  I.e., a code manager looks for ways to spend 20 hours doing code management so he can get paid when only 3 hours of code management is necessary in that particular week and 17 hours could have been spent in more constructive "helping build the story" ways. 

A: We use a simple online standup form to find out what people are working on, and we look for cases where a person is not working on the things that we think are important.  Ideally, we can encourage everyone to work on the most important stuff each day.  We think this works better if our project leader is a “tech lead” and knows the details, rather than a less technical scrum master or project manager.  The process should go around obstacles, such as people who don’t want to participate in the methodology or people who are not strong contributors for other reasons.  In the future I would like to do some sort of “gamified” contribution board, so that people can see how they are doing.  That might encourage people to work on tasks that we think are valuable.

Q: What do you recommend for a small team that does development as well as production support? What's the best practice to accommodate the workload?  Currently we do not use a Kanban or scrum tool.  We have Issue Tracker and mostly issues that we have to resolve quickly.  For development we have project work. This can be new features, enhancement, existing, bug fixes.

A: At Assembla, we keep a ticket list only for support cases.  However, if these require a response from the developers, we mix support issues into the ticket list for our development project.  We’re using the Toyota Jidoka / Lean idea of “Stop the line” when we run into an important problem.  We have a separate milestone called “Fix Today.” If something goes into that milestone, we stop and fix it.  If the issue is less urgent, then we just put it into the Current work bin with the other tasks, at an appropriate priority level.  Our system will show “high” priority tasks on top of the stack in most views.  I personally don’t think that there is a big difference at the task level between customer problems, bug fixes, enhancements, and new features.