Posts Tagged ‘SCRUM’

Prioritising stories within a sprint?

Wednesday, February 10th, 2010

In a recent post Karl Scotland drew my attention to this post by Craig Dickson on Agile DZone. Karl and Craig differ on their approach (when working with Scrum) to prioritisation of stories by the product owner within a sprint.

Craig has a valid concern that we might loose sight of our Sprint commitment if we have high and low priorities within the sprint, what if we don’t get to low priority stuff, well it was only low priority! He also raises concern over the degree to which the team is empowered if the Product Owner specifies a priority order for within the sprint.

By contrast Karl has his focus firmly on WiP (work in process), and through that lens the sprint is secondary to a focus on flow, prioritisation will encourage the team to focus on flow. I have some sympathy with this point of view.

As is so often the case I feel that I fall between these two camps.

  • I believe in an empowered team who pull from the backlog
  • I believe in the team making a commitment to a sprint scope
  • I believe in the team self-organising around moving that scope through to releasable product

But, there is always a but, these things don’t preclude prioritisation.

We pull from the backlog in order to take into account team capacity / capability. We pull in the correct amount of work with an appropriate profile e.g. not all database heavy wok if we have limited DBA capability. This means that the team may not always pull items from the very top of the backlog. The team commitment is an open honest expectation that this work can and will be achieved by the end of the sprint. We don’t sack or punish the team if a commitment is missed, in fact it could be argued that the commitment should be missed from time to time due to special causes. We don’t want to pad sprint plans with high amounts of contingency. Finally the team self-organise around achieving the goal.

When I introduce teams to Scrum I recommend working against a prioritised sprint backlog. Why? The prioritisation helps in a number of ways:

  • The team is challenged to find ways to move stories to Done faster
  • The team is encouraged to collaborate and help each other out in favour of picking new tasks
  • We bind people to tasks late, prioritisation helps them select tasks according to team need rather than specialisation
  • Where a sprint commitment is missed we loose 1 story rather than a bit from each story.

So in short, I agree with much of what Craig has said, it should not be the responsibility of the PO to prioritise the sprint backlog. However, I do see the need for the team and PO to collaborate in order to ensure that the needs of the business do not take second place to the needs of the process. I also share much of Karl’s motivation with respect to limiting WiP and achieving Flow.

For me prioritisation is a strategy that a team can use to self organise around a given sprint commitment. It encourages collaboration and mitigates risk, how can that be bad?

Tags: , ,
Posted in Prioritisation, SCRUM, WIP | 2 Comments »

Tale of two SCRUM stand ups

Tuesday, February 2nd, 2010
I walked past two teams doing their daily SCRUM standup today. Both teams claim to be agile. I didn't join in (even as a chicken) but just observed for a minute or so.

The first team was sitting down in a breakout area. Their body language spoke volumes. There was not one single participant maintaining eye contact with anybody else. Two people were playing on their phones. One developer had his head in his hands. Most had bored expressions. The team leader who is also the SCRUM master was the only person who spoke for the entire time I watched.

The second team was stood in a space near their desks. They were gathered round a task board which appeared to be up to date and the focus of several of the individual's updates. One person spoke at a time. Almost everybody appeared to be paying attention to whomever was speaking. Most updates were short and concise. A couple rambled on.

Other than both teams calling their meeting a SCRUM I could see no similarities.

As our agile adoption has spread beyond the original teams I suppose it is inevitable that as the experience gets spread a little thinner that people will simply label their existing activities with agile sounding names. Often we have no clear remit in those teams to supply a mentor and to try offer advice would result in rebuttal as team leaders guard their territory. Does this matter? Is there a risk that these teams who are not practicing agile correctly will diminish and discredit agile in the eyes of our programme managers? This is sounding a bit like an excuse for an Agile Inquisition going round checking that no team is using Agile's name in vain. This cannot be a good thing either.

Tags: , ,
Posted in Agile, Agile Management, SCRUM | No Comments »

Task boards and kanban boards

Tuesday, October 27th, 2009
Karl has offered this post explaining the difference between a task board and a Kanban board. He draws attention to the common task board focus of tasks to do this iteration. No WIP limit, only tasks currently in development. This differentiator becomes less apparent when we look at how teams develop their use of task boards. Personally one of my prime reasons for using a white board over an electronic tool is to open up the possibility of the team changing the layout. It is common for teams to apply the mantra, don’t start something new if you can support an existing activity. In addition to, always ensure that you are working on the highest priority story to which you can contribute. While this is not a fixed WIP limit it does reduce the work in progress in terms of both tasks and stories. It is also quite normal for a team to choose to show upcoming stories where early analysis is due in preparation for a sprint. Add to this a column for acceptance testing, again not unusual, and we begin to see similarities. I really appreciate the contribution that the Kanban community have made to our collective body of knowledge. However, it may be beneficial for them to more openly recognise the broad overlap in values between Kanban practitioners and the rest of us agile folks.

[Post to Twitter]

Tags: ,
Posted in Kanban, SCRUM | 1 Comment »

To SCRUM or to Kanban? – Which one fits.

Tuesday, July 28th, 2009

SCRUM and Kanban (as applied to software development) are different. Proponents of the two drift from staunch opposition to declaring Kanban as a special case of Scrum.

I have been practising and coaching Scrum for a number of years and I delight in the effect it has on project teams. While I practice Scrum I find that Lean Thinking can both help me communicate Scrum and help teams to become more effective in applying Scrum. This way of thinking led to me becoming interested in Kanban a year or so ago since when I’ve being most concerned with where I ought to recommend Scrum and where Kanban.

Recently I have spent time with maintenance groups for whom Scrum would be a poor fit. Kanban offered me an alternative when the client was leaning towards a ScrumBut implementation.

There are some fundamental differences between early project / product development work and the later stages and I don’t see this as a problem. Toyota themselves hold two separate approaches. The Toyota Production System (TPS) is the most widely known Lean Manufacturing implementation. This is the world of work cells, standardised work, Kanban boards and Andon lights. However, when Toyota want to create something new they use the Toyota Product Development System. This approach focuses on a chief engineer holding a vision and rallying a team around him. High bandwidth communication, discovery and experimentation are the order of the day.

So back in a software development context Scrum was designed to manage uncertainty and complexity, to foster high band width communication and seems a valuable fit for early development.

Corey Ladas in his ScrumBan Book declares the following Axiom for applying his application of Lean to software development

Axiom 2: It is possible to develop any value adding increment in a continuous flow from requirement to deployment

Corey makes it clear as he progresses that this well defined workflow is critical to his desired approach. In a new development that workflow is often not known and usually not linear. Rather the team swarm over the requirement often returning to the customer for feedback before offering a completed deployable feature.

My suggestion is this, Scrum is a powerful approach to managing uncertainty as well as being a supportive environment for building a team. I believe that one goal of product development should be to reduce the uncertainty and evolve the workflow. As adding features becomes more straightforward we may find that we are in a state akin to production and can take advantage of a Kanban approach to further optimise for reduced cycle time, increased throughput and just in time scheduling.

[Post to Twitter] 

Tags: ,
Posted in Agile, Kanban, SCRUM | No Comments »

Managing WIP with Scrum

Tuesday, June 30th, 2009

Recently I’ve mentioned, both on groups and blog posts, the fact that many limiting Work In Progress in reserved for those taking on Kanban Software Development.

In this post I’d like to share a couple of the techniques / approaches that I use in managing WIP within a Scrum framework. These tools may be useful to you in order to improve an existing Scrum team or as a step in moving towards Kanban (see also Scrumban by Corey Ladas).

Daily Management

Members of an agile team should be empowered and trusted to work on the right thing. This may be helping out a colleague or fixing a broken build as well as building new features.

In order to encourage the right behaviour I propose the following filter to new teams. When looking for the next task to work on:

  • Is there anything I can do to assist a colleague in moving a high priority task to Done?
  • What is the highest priority task on the board that I have the skills to take on?

This has the effect of keeping the task in progress to a minimum as well as weighting the teams effort towards the top of the board (i.e. towards higher priority stories).

Some of the teams I have coached have had a code review column that development tasks must flow through, reviewing some code would be one way of assisting in getting to Done.

The effect of this approach is to minimise the stories in progress, maximise the chances of completing the higher priority stories in the iteration, encourage swarming over tasks and stories.

Project tracking

Many Scrum teams use burn down charts. Consider using a burn up chart, this provides visibility into changes in scope as well as room for further improvements as you’ll see in a moment. By tracking two lines representing scope and done we can our progress towards some milestone. In the example below blue shows the known project scope and green is work done by the dev team.

200906301135

It is common to do some early analysis work before an iteration to ensure that the acceptance criteria of a story are known before the sprint planning meeting. We want to ensure that we don’t over invest in this analysis work retaining a healthy buffer of stories ready for development. This part of the scope that has been analysed can be shown on our burn up chart, yellow in the example below. Here we can see where analysed work is building up.

200906301139

Of course if we are doing this we may also add an analysis column to the task board along with a ready for development column.

Another category of work common in Scrum teams is post iteration testing. After the demo we hand off work to a QA or UAT group that validate the requirement has been met. By recognising this work we continue to expand our view along the value stream. Below I show in red the work that has been accepted by QA. This demonstrates a problem in the system which was not made visible by the original chart. We can see that work that is developed but not tested is building up. If we care about WIP and cycle time then this is a problem, also if we care about project success we should consider this to be a build up of risk.

200906301143

A final line could be added to show the deployment of software. A delay in deployment can mean missed revenue earning opportunities as well as a missed opportunity to learn and react.

I use these type of charts (Cumulative Flow Diagrams) as an aspect of project reporting in order to expose a more complete view of the development process beyond the confines of the Scrum team.

Also, where applicable I will augment the task-board with these extra states to show more project context to the team.

[Post to Twitter] 

Tags: ,
Posted in SCRUM | No Comments »