When to raise the Work in Progress limit

Although not a specific practice of Scrum, we often use Work In Progress (WIP) limits to ensure that our team focus on complete a requirement before starting a new one.


When working on a project that has a WIP limit which is lower than the number of team members there will be times when a team member feels like they cannot contribute to the current work in progress.


This can make them fell like they have nothing to do and the automatic reaction is to update the WIP level, but before do you should ensure that you have tried all of these possibilities:

• Can you work with other team members on any of the other In Progress stories to allow them to be complete faster?  
  • Can the work be split up into separate tasks?  
  • Can you pair program with another developer?
  • If using unit tests can you help write appropriate tests for the functionality?
• Can you fix any bugs?
• Can you help unblock any stories that are in a Blocked state?
• Can you make a release to test?
• Can you improve the release process?

Only after finishing all of these tasks should a team even think about increasing the WIP level.

Continuous Retrospectives

At the end of each Sprint, teams should have a Sprint Retrospective to get actionable ideas for improvement for the next sprint.  Good, bad or indifferent, the points are discussed to allow the team to praise, vent and reflect.

However, in a 2 week Sprint a lot can happen.  The Sprint could have started badly and turned out well, for whatever reason.  In cases like this the retrospective will most likely focus on the points that are fresher in the memory rather than providing an overall view of the sprint.

To get more realistic actions from Retrospectives and to quicken the inspect and adapt cycle we often use Continuous Retrospectives.  Our team write down any item they want to discuss during the Retrospective and add these to the task board.

We choose an appropriate number of items to act as a catalyst for a retrospective.  So if our limit is 3 items, we must have a retrospective once any 3 items are added to the board.

This allows is to quickly resolve issues meaning we can see benefits immediately within the current sprint.

Meet the acceptance criteria, don't exceed it

During the initial sprint reviews for our current project it became apparent that the team weren't meeting the acceptance criteria for the user stories that made up the Sprint Backlog.

Our retrospectives helped us find that this was generally because the team over-built, delivering more functionality than was actually required to meet the stories.

The team felt that they were doing the right thing in delivering more to the Product Owner, however as they were pushing themselves to deliver a higher volume of functionality they lost sight on delivering high quality software ultimately meaning that we were failing our client by delivering an unusable, buggy system.

This also affected our Product Owner as the additional functionality had not been previously approved by them.  If additional work was going to be delivered our Product Owner should have the authority to determine what that functionality should be.

When discussed with the team they realised the impacts that this was having and agreed to do only what was in the stories.

Information Radiators

A colleague of mine recently protested about our whiteboard and post-it note project board as he felt that we'd be much better served with an online solution so that team members who work from home could view and update any progress.

As much as this is true I argued that using a system to store progress information was effectively locking the project board and it's information away therefore making it much less useful.

A physical board sitting beside the team acts as an Information Radiator, pushing project information out to the team.   At a glance anyone can clearly see the status of the project, and any changes being made are immediatley visible as you can actually see when people update the board.

Having to access and log in to a system may sound easy enough but in practice these extra steps generally discourages a team from making updates to the board and if that happens then you lose all the advantages that a project board gives you.

Getting actionable ideas from Sprint Retrospectives

At the end of each Sprint our teams have a Sprint Retrospective.  In this meeting the team look back at the things that happened during that sprint.  Good, bad or indifferent, the points are discussed to allow the team to hopefully improve upon their performance during the next sprint.

The retrospective meeting is mainly for the benefit of the team however we sometimes ask our Product Owner along too.

During the meeting the Team are asked 3 questions:

·       What worked well last Sprint that we should continue doing?

·       What didn’t work well last Sprint that we should stop doing?

·       What should we start doing?

The Team then prioritise in which order they want to talk about the potential improvements and each item is then discussed separately and actionable items are collated by the ScrumMaster for implementation in the following Sprint.

To avoid the retrospective from becoming long, drawn out meetings we employ the following guidance:

·       Time box the meeting as these discussions have a tendency to run over.

·       Throughout the Sprint keep a log of things that happened during the sprint and things that the Team are doing differently to the last Sprint.  At the beginning of the meeting give an overview of these.  This helps focus the developers on improvements that could be made.

·       Each item raised should have an associated action for improvement.

·       Get the Team to write their points on post its and stick them to the wall.  Then ask them to prioritise the points to ensure that the most important ones are discussed first.

Viewing progress through releases

In the Harvard Business Review article on Breakthrough Ideas for 2010, Teresa M. Amabile and Steven J. Kramer note that what really motivates workers is not recognition or incentives but rather the feeling of progress.  They write that from extensive study of workplace activities  it has been found that "On days when workers have the sense they’re making headway in their jobs, or when they receive support that helps them overcome obstacles, their emotions are most positive and their drive to succeed is at its peak".


I recently remembered this article when discussing the benefits of Scrum with a client.  When using Scrum the overall project progress can be demonstrated using a Product Burndown Chart as this shows the overall progress through the Product Backlog.  However this must be used carefully as the Product Burndown can increase over time as new features are added to the Backlog.


The addition of new features to the Product Backlog should not be discouraged, the fact that new requirements can be easily and quickly added to a Product Backlog to deliver the greatest ROI in the shortest time is one of the main advantages of Scrum.  However the Product Burndown may not be the best way to show progress within your team as they may mistake the addition of items to the Backlog as negative progress.


Instead, planned, regular releases, occurring after a set number of Sprints, each with specific goals, can give your team the sense of progress that they desire.  With each successful release being celebrated and reviewed.  The release need not be shipped, rather it is used as a target for developers, a goal with which they can gauge their success.


Within a project with a large number of Sprints the completion and release of a Sprint can in time become the norm and the view of progress being made can become hazed.  With the addition of releases the team have larger goals allowing them to assess their efforts and more importantly view their progress throughout the project.

Its a review not a demonstration

At the end of a Sprint the team get together with the client to review the work that has taken place over the Sprint in a meeting called the Sprint Review.

On some of our projects this meeting has been under-utilised with the developers completing a demonstration of the system.

Why is this a problem?  Well, the demonstration is a scripted display of the work that has been completed.  The developers will, completely subconsciously, click on what they know works and keep to a minimum any time spent demonstrating things that don't work so well.

This means that the client walks away without fully understanding what has been delivered and therefore can't accurately specify what is required during the next Sprint.

Sprint Reviews should be interactive sessions.  The team should show each story in turn with the client asking questions and interacting, hands on, with the system.  This way both the client and the team can agree on what is really done and can together understand what the contents of the next Sprint may be.

Choosing the length of your sprint

Our development team generally work on projects with sprint lengths of 2 weeks.  However over the last few months we've been experimenting with different iteration lengths and on a recent project this was set to 1 week.


We decided on this length as, when we started development, the requirements for this project were in a state of flux and we felt that a shorter 1 week sprint would give us the most flexibility to deliver the changing priorities.

As the Product Owner continued to drastically change their priorities it became clear that the shorter sprint did allow us the flexibility we needed to continue to provide value to this particular client.  However there were a number of challenges that this created.  During a 1 week sprint our team found it hard to find a rhythm to their week, it was almost as if they were always trying to catch up in order to deliver their committed requirements.  This lack of rhythm was visible in the sprint burndown which didn't seem to find a flow, meaning that we couldn't use it to predict if we were on track to deliver or not. 

Also, there was a lot more overhead with twice as many planning and review meetings than we normally had, meaning that there was less time for delivering requirements.

These byproducts caused our team to tire quickly and we wouldn't have been able to keep up this pace for longer than 5 or 6 weeks.

Our team found that shorter sprints are possible, and sometime necessary, however the pace can be difficult to maintain for more than a few weeks.