Prioritising stories within a sprint?

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?

Mockups with Balsamiq

Many of the practices that we apply in agile development teams emphasis deferring commitment. This is one of the ways we stay agile. If we have written a sentence on a story card and subsequently decide we don’t need that story we can rip it up, very little has been lost. Compare this with costly requirements specifications, a small change can trigger significant re-work.

In the same way, when specifying a user interface it can be helpful to defer commitment while expressing the need succinctly. Often we can use white boards and/or paper mock-ups to develop screen flows in meetings with customers. This can help us play with alternatives and walk through scenarios while avoiding the cost of mocking up in html or photoshop.

Balsamiq Mockups offers the logical next step. By retaining the style of a paper mock-up we can avoid becoming too attached to one design. A slick user interface helps us build screens quickly and provides most of the components we are likely to need.

However, for me the killer feature is the confluence integration. I use confluence every day, many of my clients use confluence for project documentation, this integration means that the documents can be found by all concerned, edited in place and version controlled.

Technorati Tags: Agile Requirements, Balsamiq Mockups

Splitting user stories

I should start this post with an admission – I do not claim credit for any original thought here. What follows is taken from my own notes and has been accumulated over a number of years. I most recently tweaked my own notes and the way I explain this stuff after hearing Jeff Patton’s talk from the UK Lean Kanban conference on infoQ.

The way I think of splitting user stories is through identifying axis. Some examples of axis are:

• Steps in a workflow
• Usability
• Quantity of data
• Asymmetric value
• Stakeholder needs

Steps in a workflow

The first of these is fairly self evident. On a recent project we had the need to implement a user story to purchase an item. This fell into an initial workflow design and mock-up stage followed by 4 user stories relating to the four stages of the workflow, checkout, select shipping method, submit order, order confirmation. This approach enabled us to deliver working features based on mock-ups followed by iterative improvement.

Usability

Another approach to the same problem could have been to split along a usability axis. This would involve and early “ugly” version followed by iterative usability improvements. This approach can be more effective if the screen design is novel and uncertain or the technical risk around order submission is being brought forward as a mitigation. A further usability axis would be to separate core functionality from enhancements such as auto-completion and other AJAX magic. A further example that comes to mind is a search capability, initially searching was by full words only on one field, gradually the back end was enhanced to do partial words and check multiple fields. At the same time the search results view was being enhanced to enrich the user experience.

It is in this category that we see Patton’s considerations of Bare Necessity, Capability & Flexibility, usability, performance, sex appeal manifest. His final axis is Safety which more clearly maps to stakeholder needs below.

Quantity of data

Quantity of data can be an issue where it significantly impacts the size of a task. For example where the datasource differs. It may be possible to establish a workflow while limiting the variety of variation of inputs or scenarios. An example might we limiting a registration form to accepting only a minimal customer details or limiting a report to showing a subset of the data. The later approach may allow some proof of function and review of layout earlier than if all data sources / types / fields were considered.

Asymmetric value

Value is a core consideration with user stories. It may be worthwhile considering how the value of the user story is gained. I worked on a system some time ago which was incrementally adding features in order to retire an older system. Our key goal was to minimise the users interaction with the old system. The user story under consideration was “create and trade financial instruments”. It turned out that while at first glance these were an atomic unit the users would trade instruments many more times that they would create them. Thus, we could reduce the users interactions significantly by providing the trade facility requiring the users to, in the short term, create instruments through the older system.

Stakeholder needs

Despite the name “User Stories” and stakeholders needs can be represented as a used story. During development it can be useful to view a user story from the perspective of security, operations, finance (and others) where one of these places a significant burden on a user story it may be appropriate to separate the two goals. An example of this can be as simple as data validation e.g. post codes or Captcha fields which do not benefit the user but some other stakeholder.

If all else fails

We could always fall back on using architectural lines to split a user story of breaking out a component that needs to be built. This approach is often at the top of the list when developers begin to consider splitting stories. I prefer to leave this as a last resort, we shouldn’t deny that it is an option but as my experience in splitting these things has increased it is a resort that I find myself reaching for less and less.

Technorati Tags: Agile Requirements, User Stories

Agile requirements – back to basics

Much has been written about User Stories however, it is still a subject that I find people struggling with.

In this post I intend to review what are the choices that we make that enable us to claim a requirements approach as agile and how can user stories (when applied well) help us achieve this agility.

An agile approach to requirements should

• Defer investments
• Support just in time elaboration
• Encourage collaboration
• Support planning

The most common approach to agile requirements is User Stories. A user story represents a need on behalf of a specific stake-holder.

What is a user story?
User stories represent a need in terms of the individual who would benefit and the goal they are trying to achieve. For example an on-line book seller might have the story: As a customer I would like to search for a book by ISBN so that I can make a purchasing decision.

User stories can also be written on behalf of stake-holders who may never interact directly with the system, for example: As a support representative I would like the system to log activities and errors so that I can establish cause of a failure. In this way stories can be written to represent other aspects such as audit, testability, extensibility and performance requirements.

By representing stories in this way we can provoke valuable discussions regarding true need of a feature and it’s relative priority in the backlog. It is not uncommon to find teams working on what seems like a sound requirement that, when represented in this way, is shown to have little or no value.

So how do user stories meet the desires stated above?

Defer investments
A user story can be expressed at a very high level early in a development project. As the story moves over time towards the top of the backlog it can be split. This approach results in small items at the top of the backlog and large items at the bottom. The items at the top have been split and appropriate details added such that they are both small enough to deliver in an iteration and detailed enough that work can begin. Low priority items may never justify this degree of investment.

Support just in time elaboration
A story is often said to be a trigger or promise to have a conversation. With an on site customer a card with a few notes may be sufficient to trigger that. With non-instantly available customers we may choose to gradually build up the detail and supporting information (e.g. acceptance tests / criteria) prior to development commencing. The key here is to avoid the temptation to elaborate all of the user stories up front.

Encourage Collaboration
As user stories are elaborated we will need to engage with business stakeholders, user interface/experience designers, testers and developers (maybe others too) in order to establish the true requirement. As conversations of this type continue throughout the project we achieve a shared appreciation across what could other wise become distinct areas of the project.

Also, the way we handle these things can further enhance collaboration for example WIP limits and short iterations both place a tension on teams to find ways to collaborate.

Support Planning
Planning is usually necessary to answer questions like; when will it be done? and how will I know it’s on schedule?

User stories are often estimated using planning poker. This provides a low cost way to compare relative sizes. We can do this at low fidelity with very little information to support long term plans. For shorter term targets we can break stories down and add detail to gain a higher fidelity estimate. When planning an iteration we may be able to break down stories to such a degree that they can be scheduled and delivered in a couple of days. Where this is not possible a task break-down may be used to gain an appropriate fidelity for setting expectations for the next 1-4 weeks.

So where can I find out more?

See what Ron Jeffries has to say on the subject of the 3 critical aspects of user stories

• Card
• Conversation
• Confirmation

Also, Mike Cohn has plenty to say on the subject. Not to mention his book User Stories Applied which is available on google books!

What next?

In this short post I’ve mentioned splitting user stories more than a few times. In the next one I’ll provide a number of techniques that will support you in ensuring that your User Stories are the right size for today.

Technorati Tags: User Stories, Agile Requirements

Reviewing a project initiation

I was recently asked to help a client kick-off development of a new product. This was to be their first “agile” project so the kick-off had to set the scene for the collaborative development approach that was to follow.

I used a variety of tools and techniques to bring the project to life. As is usually the case, some worked better than others so I thought I’d review the approach and describe some of the issues and possible reasons.

The agenda for the day was:

1. Review project vision and goals
2. Establish key priorities and concerns
3. Establish candidate releasable chunks
4. Decide what to do first

Attendees included the development team, development management and business sponsors.

Read the rest of this entry »

Theory of constraints for beginners

Take-away #3 from David Anderson’s Kanban Coaching workshop.

A discussion of Kanban can only go on for so long before the subject of the Theory of Constraints comes up. In this post I’ll try to explain just enough to show this connection.

Theory of Constraints (TOC) is a large subject that I was first introduced to some time ago by Pascal Van Cauwenberghe and his explanation of the 5 focusing steps for process improvement. Since then I’ve seen TOC pop up at a few Agile conferences. The most notable aspects that tend to be discussed are the 5 focusing steps mentioned earlier and the TOC thinking tools. The Thinking tools offer techniques for root cause analysis, problems solving, conflict resolution and planning. While there have been a number of books explaining these techniques the source material is a set of novels written by Eliyahu Goldratt the first being The Goal: A Process of Ongoing Improvement.

David’s first book (Agile Management for Software Engineering) was focused on applying TOC in a software engineering context so I guess it’s not surprising that he wold choose to spend a little time explaining the connection between Kanban and TOC.

At this stage I should say that where David has applied TOC he has subsequently realised that a Kanban approach would have led to an equivalent result and is a conceptually more simple approach.

The areas of TOC that David chose to focus on were the classification of bottlenecks and the application of Goldratt’s 5 focusing steps. Read the rest of this entry »

Lean decision making

Take-away #2 from David Anderson’s Kanban Coaching workshop.

This post will be short and sweet. It’s not a revelation but it is a simple pattern that can support us in making the right decisions as we evolve and improve development processes.

Value trumps Flow
Flow trumps Waste reduction
Eliminate waste to improve efficiency

This mantra might be deceptively simple. We need to consider each aspect in turn.

Value
In a Lean sense value is in the eyes of the consumer. Activities can be classified as value adding and non-value adding. Classifying activities isn’t always as simple as it sounds; development = value adding, fixing defects = non-value adding but what about testing? If you’re not sure then answer this, would you do more of it if you could? Remember, not every non-value adding activity can be eradicated in the short term.

Flow
In this context flow refers to the uninterrupted adding of value from concept through to realisation. When presented with a need we should seek to fulfil it in a continuous chain of activities with minimal time in queues and minimal delay.

Waste
There have been a number of attempts to define waste in software development through comparison with manufacturing industries. In the Kanban class David chose to classify wastes as transaction & co-ordination costs, failure load and depreciation of assets. I believe that this could form a useful framework assuming that we accept a certain amount of waste as necessary.
For example daily stand-up meetings are certainly not value adding and fall under the category of coordination costs, however, they are a necessity in the contexts of many teams. Perhaps more on waste in another post.

So, to reiterate, value will trump flow where we choose to disrupt flow in order to meet an opportunity. An example of this would be a new requirement that must be expedited in order to minimise the cost of delay. An expedited request will cause delay in all of the other in-flight requests.

Next we choose to trump waste reduction with flow. This is most visible where we introduce buffers to ensure maximum utilisation of a bottleneck activity. Recall that the theory of constraints teaches us that the throughput of the bottleneck determines the throughput of the entire system. Where flow is somewhat ragged we will introduce a buffer to ensure that work is available. Buffers can be considered wasteful, however, the benefits of the increased throughput out-way the benefits of reducing inventory. Another example might be the introduction of non-value adding activities at non bottleneck stations that, while wasteful in them selves, might serve to improve flow through the bottleneck.

Finally we aggressively eliminate waste from the system in order to improve efficiency while remaining conscious of two temptations:

• to use economies of scale to hide transaction costs
• drift into ‘analysis paralysis’ for fear of failure load

Technorati Tags: Kanban, Kanban Coaching

Why Kanban

Take-away #1 from David Anderson’s Kanban Coaching workshop.

Kanban (as applied to software development) has created something of a buzz over the past few years growing out of a couple of case studies of David’s along with the experiences of the likes of Arlo Balshee now we have many more experiences from a variety of contexts.

Given this it was interesting to reflect on why a Kanban approach might be right for a team or organisation looking to adopt an agile way of working.

David highlighted a number of reasons why Kanban might be the right approach including:

• Optimising an existing process is easier and more effective than trying to introduce a new one
• Provide what execs want
• Achieving high maturity

The first of these points challenges the approach that many process improvement initiatives have taken in providing new job titles, new process, new document templates and more. By contrast where an organisation has an existing process, possibly with specialisations and tooling in place, a Kanban initiative would seek to model existing workflows and expose issues leaving job titles and working methods intact. This approach is likely to meet less opposition since it cut’s less to what individual contributors care about and identify with. In addition a Kanban system should generate metrics that inform further improvements, for example to working practices. With luck, by this point sufficient buy in will have been achieved to minimise objections.

The second point cuts to one of David’s mantra’s. Exec’s, he asserts, all want the following:

1. Predictability
2. Business Agility
3. Good governance

In addition David likes to emphasise

• Empowerment without loss of control
• Self organisation without fear

Two aspects of David’s approach to applying Kanban appear to contribute a great deal to keeping these promises. The first is an emphasis on metrics. Particularly where an electronic tool is employed a Kanban system can inform a wide variety of management decisions. This is often missing where agile teams rely on a more emotional output from retrospectives. The second aspect is the exposing of policies. Many classes of issues that constrain the performance of development teams can be described as policies. Once de-personalised these can be considered with respect to the risk that they serve to mitigate and the benefit they bring as contrasted to the over-head.

And finally we come to the maturity argument. A high maturity organisation will be able to; make statistically defensible decisions, implement causal analysis and resolution and effectively deploy process improvements.

While a Kanban system will provide a rich set of metrics and enables the application of a great deal of knowledge accrued in the management of pull systems, it’s great strength (from my perspective) is process improvement. A Kanban system will make any mismatch in capacity between specialists visibile. The board can be annotated with information regarding blocking issues. But, best of all, where a blockage occurs the Kanban system will release resources to deal with the constraint.

Given this focus it seems likely that a Kanban approach may appeal to a class of organisation who see little appeal in more developer centric approaches. Kanban offers a tool set for the management of knowledge work. However, while Scrum and XP expose trust and respect as key principles these remain a choice for the manager applying Kanban.

Kanban Coaching Workshop

OK, I’m a little slow on the uptake here since “real work” is proving to be something of a distraction.

Last month I was fortunate enough to attend David Anderson’s Kanban Coaching Workshop. Here is how David described it:

This 3 day workshop is for experienced Agile coaches, existing Kanban practitioners, and those who have previously taken David J. Anderson’s Kanban class. This workshop is intended to be an interactive collaborative session designed to facilitate knowledge sharing and learning. The class will be divided into approximately 10 sections with a slide presentation or tutorial from David to introduce each section. The goal is to enable participants to go back into the field and successfully coach Agile/Lean transitions using the Kanban approach. Each participant will received a personal recommendation from David J. Anderson as a result of participating in the class.

The three days were run in a very interactive style with 8 delegates including myself. Since all of the delegates were either Kanban practitioners or practicing agile coaches the discussion was both lively and in depth.

Subject matter covered a wide range including:

• Motivations for introducing Kanban
• Getting started with Kanban
• Comparing Agile and Lean decision making
• David’s “recipe for success”
• Reviewing David’s Microsoft XIT case study

Rachel Davies has already blogged some of her isights from the workshop here and I plan to add a few of my own key take-aways over the next few posts, these will be grouped under the Kanban Coaching tag.

Cause and effect in retrospectives

Thanks to Rachel Davies for sharing her approach to constructing a diagram of effects.

Rachel proposes that the diagram of effects can trigger a team to discuss how a variety of issues relate and goes on to highlight advice from Bas Vodde and Craig Larman in their first book “Scaling Lean and Agile Development”, the First Law of Diagramming is “The primary value in diagrams is in the discussion while diagramming—we model to have a conversation.”

I have been using a slightly different approach in retrospectives recently. With a similar intent to Rachel I hope to trigger conversations that result in a team sharing there concerns and issues and coming to a shared view as to how these relate and where would be a good point for intervention.

I’ve used this approach a couple of times recently when running retrospectives that cover a few months i.e. not iteration retrospectives where we choose to commit a few hours to investigating issues in some detail.

My favoured approach is borrowed from Eliyahu Goldratt’s Theory of Constraints, it is one of the 5 TOC thinking process and is know as a current reality tree. A current reality tree is a tree of undesirable aspects of your current situation, these are connected to indicate cause and effect.

My approach to constructing this diagram is as follows:

Identify undesirable effects
Invite the whole team to stand around a table thinking of undesirable / unwanted traits of their existing approach (process, tools, methods etc.). Each item should be written on an index card and placed on the table in no particular order. Team members can try to avoid duplicats but if one pops up it is not a problem.

Begin to identify cause effect relationships
Invite the team to select two related cards. These should be stuck on the board and joining with an arrow pointing from cause to effect.

Continue to grow the diagram
The whole team should collaborate to add the cards to the diagram. When I first tried this I wondered how I would cope if groups of cards were not related. I’ve not seen this actually happen yet but should it then I guess we allow for the growth of separate diagrams until we discover a relationship.

Review relationships
In CRT literature there are a set of steps for assessing the existence and relationships between UDEs. My approach is to invite team members to consider where items are missing. Often where many causes relate to a single effect there is a missing intermediate effect.

Since I tend to run this approach in a time boxed session I an looking for the point at which returns begin to diminish. As the group settle on a basic shape and begin to look for intervention points I move to support this.

A good candidate point to intervene at would be contributing to a number of effects or participating in a feedback loop. By focusing on one effect we can select actions that will contribute to reducing this effect and by association those related effects.

Of course, an added benefit of this approach is that we can use the cause and effect diagram to review the effect of our interventions; did we get it right, if not was there something we missed in the analysis?

I hope that this is useful. Do share if you’ve used this approach or something similar yourself.