Category Archives: Agile Delivery

The affinity method for estimating stories


Planning poker is quite a popular method for estimating stories, but one of the huge drawbacks on complex projects is that it takes forever, especially if you have over 20 stories.  Here is a step-by-step guide for how I guide teams through a much quicker process for estimating stories.  I have used this method with teams who have over 200 stories and we have completed the estimating session in under two hours.

When to use this method

This type of estimating is most useful at the foundations or release/delivery planning stage.  It is most useful as I have said before when there are 20+ stories to be estimated.


It is important that before you start the estimating session that the team understands what the story means.  The estimating session will have been preceded by a number of story writing workshops where the stories were discussed with the team members, but not necessarily in great detail.  So completed story cards with preliminary discussions as well as preliminary or high-level acceptance criteria feed into this process.

Clear floor space or wall space 2-5 metres is preferable

Some cautionary notes …

If your team is new to Agile you may find “observers” turning up to the session.  These may be business analysts, product owners, project managers or whatever.  I sometimes find that these people, with best intentions, want to influence the outcome.  For instance project managers are keen to please their sponsors and want to provide estimates that are often smaller than the team feels comfortable with.  When I facilitate these sessions I make the rule that the observers may only do just that- observe.  The only people allowed to estimate are the ones who will be doing the work.  Yes, OK they may get the estimate “wrong” – in fact I can almost guarantee that they will, but the team should be encouraged to learn from their mistakes and not be held hostage to the opinions of others who will not be as committed as the team will be to getting the work done.  To this end I always recommend that the session is facilitated by an experienced Agile mentor or coach who is able to deal with the difficult characters who may unintentionally (or even sometimes intentionally) sabotage the efforts and outcomes of the team before the work has even started.

The Process

Setting up the workspace

1) The far right of the workspace indicates those stories that are the most complex or most time consuming.  The far left indicates those that are the most simple or quickest stories to complete.  I like to put markers on the board to remind people of two sides of this continuum.


2) One member of the team randomly chooses a story card from the pile of stories; they read out the story to the rest of the team.  They then place that story on the board according to how they feel about the level of complexity or time to complete.

3) The next team member then randomly selects the next story and places it either to the right or the left or in the same relative position to the previous story.  A long way to the right of the previous story suggests a very much more complex story, while one a long way to the left would indicate a much simpler or easier story to complete.  The is a relative estimating method so the distance between the stories is important.

4) This continues for a few goes until there is about five or six stories on the board.

5) Once there are a number of stories on the board team members then have a choice in how to use their turn

            a) they can either select another story and place it on the board or;

            b) they can move one of the other stories.

In the instance where the member elects to move a story they explain to the rest of the team why they believe this to be so.  The team can then discuss where is the most appropriate place for the story.  I find that it is good to keep the discussion short and if there is serious disagreement in the team then err on the side of caution and put the story further to the right.

6) The process continues until all the stories are on the board.

7) Assigning the points

The outcome should now be groups of stories spread across the board.  We then allocate story points according to the rough Fibonacci sequence as we do in planning poker – (1, 2, 3, 5, 8, 13, 20, 40 & 100) – we then write the story point value on each of the cards.

Again it is important to not get too hung up on the numbers at this stage of the estimating process as finer turned estimates will be provided as the project progresses and more is known about the product we are creating.  A good point to remember is that it is better to be roughly right rather than precisely wrong especially in the early stages of the project. However it is worthwhile just retesting our thinking with some of those stories that may have been borderline between two groups, especially those of numerical significance i.e. those the are between 20 and 40 or 40 and 100.  There is no point in “dying in a ditch” over a story is a 1 or a 2 at this point.

If you have any further questions about this technique then please feel free to ask in the meantime … happy estimating 🙂

The 3 Cs of User Stories

In our consulting work we often refer to the three C’s of user stories, here is what we mean.  The C’s are abbreviations for the:

  • Card
  • Conversation
  • Confirmation

The card contains little information and is often written in the form “As A <<Role Name>> I want <<a feature>> so that <<some value delivered>>”.  There are many different forms that this can take, but what is most important is that what is written, is meaningful to the team delivering the feature and the customer (or product owner) requesting it. Developers cannot write software from the card alone and to that end they need the next part … the conversation.

The conversation is the essence of the requirement and conversations can spawn many outputs or artefacts such as models, notes, story maps or even good old fashioned code!  I like to think of the conversation as the most important part of the story because this is where the learning is achieved.

For years as a systems or business analyst I used to write requirements specifications that could sink a small boat and then lob these over the partition to my design colleagues (god I hated conversations with designers – they asked way too many questions ;0) ).  But seriously, minimising the written word to specify requirements is important, but you maybe can’t get away with eliminating it altogether.

Conversations, and more importantly evolving conversations, allow the developer/designer to hold the concepts of the requirement in their head while the design and code become the output of a requirements conversation rather than some weighty tome.  This minimises ambiguity and uncertainty as the analyst, or better yet customer, can see their thoughts become manifest as a result of a few insightful conversations.  Changes can then be made directly as the feedback is received rather than going through some lengthy change management process which will result in a document being changed giving the risk of more ambiguity.

The confirmation (often written on the back of the story card) gives us the high-level criteria against which the resulting feature will be tested against.  I like the idea of specifying the system by examples of what the system will do both when it functions correctly or incorrectly.  This is a better way of creating a specification as opposed to my boat sinking documentation of yore. Alternatively simple closed questions such as “does the screen go black?” may well suffice for acceptance criteria.  But these in themselves will not be the complete set of acceptance tests but only a high level set of tests to give the customer or product owner confidence that the feature that has been created fulfils their criteria of a working feature.

The 12 Agile Principles for Software Development

Here is a reminder of the 12 Agile principles for software development.  These have been recreated here for your convenience.  It you would like to go straight to the origin of these principles then please click here.  And yes I have corrected the americanised spelling 🙂

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity–the art of maximizing the amount of work not done–is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Scrum Ceremonies: Sprint Review

Definition of the sprint review


The sprint review is held at the end of every sprint.  This where the team demonstrate the next increment of the product to be delivered.  The meeting is intentionally kept short and informal as the formalised part of  the review will have already taken place.  The way in which the meeting works best is to run the sprint review as a product demo where the new features that have been added during this iteration are presented to the audience.

Participants in the sprint review

The audience at the sprint review can be anybody who is interested in the latest developments to the product as well as the team.  I suggest that all the team are present and will explain why in a short while.

Preparation for the sprint review

I often advise teams not to spend hours and hours preparing for the sprint review, however it is always good to make sure that it goes according to plan; so it’s really a question of doing enough prep for the meeting to make sure everything runs smoothly.  I have sat in on some of the most embarrassing sprint reviews when senior management have been in attendance (isn’t it funny how it all goes wrong then);  the team have had a most successful sprint and then they get bad PR when the overhead projector or some other technical aspect of the demo doesn’t work.  So a tip, that seems so obvious so I ask myself why bother saying it, but turn up 10 minutes before the suggested start time and have a quick run through just to be certain of success.

Running the sprint review

So everyone is set up and you’re ready to go … I find that it is always useful to spent the first two minutes of the sprint review reminding (or informing because maybe everybody wasn’t aware) everybody of  what the sprint goal was; which part of the goals you achieved and thus what will be demonstrated in the sprint review today.  I often suggest that it is the Product Owner who gives this introduction, which is contrary to what Schwaber and Beedle suggest (they suggest the scrum master coordinates and conducts the review – Schwaber and Beedle, 2002, Agile Software Development with Scrum, Pearson education, p55) I’m happy to explain my reasoning behind this slight twist if anyone is interested.  This nicely sets the scene and give a professional feel about the sprint review.  Informal shouldn’t translate as unprofessional.

I always suggest that the Product Owner requests that if anyone has any questions to wait until the end of the demo.  If necessary the team can rerun the demo in order to address any key points or questions raised.  Of course this is optional and it may be easier for the teams to answer questions as they go, because there might be a lot to set up in order to rerun the demo; the Product Owner should explicitly state that preference at the start of the meeting.  This is because often visitors might feel that it is being rude to interrupt the flow, and sometimes it is, but if the rules and boundaries are set at the start of the meeting then usually all will fall into place.

So once the scene has been set the Product Owner can hand over to the team for the demo.

It is important to note that we only cover what has been completed and has been agreed by the Product Owner to have met the required quality standard for the product.  Anything that hasn’t been completed or “signed off” is not demonstrated.  Which leads me nicely onto the real purpose of the sprint review.

The real purpose of the sprint review …

I see that there are two reasons for the sprint review.  Firstly it offers the attendees the chance to understand and see for themselves the progress that has been made on the product.  It might be necessary for the Product Owner to discuss where this fits into the overall scope of the product delivery in the introduction at the start of the meeting.

Secondly the sprint review offers the team a chance to bring closure to their work for the  duration of the sprint.  The items or features that are demonstrated are considered to be closed and thus any outstanding requirements or other associated documentation is considered to also be closed.  This gives the team an opportunity to celebrate their success on meeting their goals and it is an opportunity for any senior management present to recognise and affirm the efforts of the team.  This is why I said earlier that it is important for all team members to be present; everyone needs to feel that sense of closure and completeness for the work carried out in the previous iteration.  Equally so, everyone deserves to share in the recognition of the work done to date.

What a sprint review is not …

      • It is not a meeting designed to critise or for the team to take further actions for improvement to the product. It should be noted that this meeting is an informational meeting that raises awareness of the goals achieved thus far   These are channelled through the product owner in the subsequent requirements gathering phase.  Therefore it is not a Go – No-Go meeting.  If the product is not considered fit for purpose before the review then my advise is to cancel the sprint review; the product owner can inform the necessary stakeholders as to why the product was considered to not meet the teams definition of done.
      • It is not death by PowerPoint.  I don’t like to be too directive on this point because PowerPoint does have its place; but the main focus should be on the demoing the product itself.  This is not always possible and some other means of demonstrating progress can be creatively considered without the use of PowerPoint.
      • It is not a document review meeting.  Documents are often a necessary output from the product development process.  If a document has been created it should be quality assured before the meeting and the smallest of introductions to identify where the document is stored and that it has been formally signed off according to the previously agreed definition of done.

Do you have any other tips for my other readers?

If you have any tips on how to run a successful sprint review then please submit them in the comment box below.  I will also give a link back to your site in return.  Thanks.



Something Agile Leaders can learn from Steve Jobs

Ok – maybe there are lots of things that Agile Leaders can learn from the  late Steve Jobs, but here is just one particular example.

Focus to bring business value …

Steve JobsIt is reported that when he returned to Apple in 1997 Steve Jobs reduced the number of Apple products from 350 down to just 10.  Why did he do this?  Surely a company would have more chance of penetrating the market with over three hundred products rather than just 10. Well, no.

One of the main values of Scrum is focus.  The creators of Scrum understood that there is only a certain amount of meaningful attention that an individual or a team can apply to a problem in any given time, otherwise the level of noise in the team just increases.  The same is true for organisations also where the cost of maintaining a product or service continues to demand attention long after the product has been created and delivered.

Focus as a cornerstone value for Agile business practice

One of the important things a leader must do in their organisation is to continue to critically appraise which products they want their teams to work on.  I was asked to by a senior manager in an organisation to sit in on their weekly review board and provide some Agile consulting to her and the other attendees.  I made an observation about the number of change projects that they had ongoing.  There were over fifty projects of varying sizes and complexity.  Her comment back to me was “well that’s what’s expected to be done around here”.  We had some more discussions on this point but in short the organisation continues to fail to meet all of its targets and is continually playing catch up on meeting its commitments with its clients.

Why wont leaders change?

There is a fear that prevails in many senior managers that they must be seen to be doing more, yet they will have heard the expression “less is more” but they will continue to respond to their fears rather than the needs of their customers. Customers may not often want more, but they do want quality.  This is why Apple excelled at what they did.  (I use the past tense because I’m sure there are many like me who are waiting to see if the Apple culture of creativity and quality will continue in the absence of one of the most inspired leaders the world has known.)

The solution …

Prioritise.  Again experience informs me that is an often uncomfortable conversation I have with senior managers who believe they want it all and they need it now.  I explain about focus and attention; I talk about sustained pace of the team; I implore on the basis of better quality and motivated teams;  but the justification that I am given is that they don’t want to fall behind the competition; or certain stakeholders will expect these features or changes or some other form of rationalisation that make their demands right.

In short by asking a senior manager to prioritise  I am asking them to take more time to think about where their priorities lie and as a result what they should focus on. But all too often it is easier to to put more pressure on the product delivery teams to deliver more and quicker.  This keeps the managers from making painful choices and having uncomfortable conversations that involve saying no to stakeholders.  This is not leading but passing the buck and the consequence of these types of decisions that put more pressure on the delivery teams is poor quality and as a result poor customer satisfaction.


It makes me wonder what would have happen if Steve Jobs would have allowed his executive team to continue working on over 300 different products.  Would we have ever seen the ipod, ipad, iphone or itunes? And if we did would we have seen lesser versions of these products that would have annoyed us?  In short there is much business sense in focusing our resources on doing a few things well rather than a lot things mediocre. Remember less really is more.

About the Author

Mark Buchan is an Agile consultant  with experience of delivering organisational transformation for his clients.  He has worked with organisations such as Rolls-Royce, Nokia, Bupa and BT.

You can view Mark’s profile on linked-in

You can also follow him on twitter

On Time, On Budget, Happy Customer

When I first came up with the idea of this website I thought it might be rather hypocritical of me to look at its delivery as anything other than Agile.  So I looked at the “Iron Triangle” of time, cost and features and decided that my budget and time were the two elements to remain fixed while I flexed on the features delivered.


To my mind the core of Agility is the ability to flex the requirements in the face of changing environments (both internal and external).  This doesn’t mean that I wont get the features I want – ever.  No; what it means is that I prioritise what’s important to me up front and make a decision to focus on the features that deliver most business value.  This is a common misconception about Agile delivery; business think that unless they prioritise everything in the product as a “must have” requirement, then they wont get it at all.  The reality is we focus on fewer items in the short term to order to deliver the right thing for our customer.  We can then successively or incrementally add those set of features in future releases of our product.

Delivering Business Value

A key question that was important for me to address as the Product Owner of my website was “what delivers greatest value?”.  In the past I had convinced myself that sexy websites with all the bells and whistles were what would sell the services that I offered.  Wrong! As I have become to understand my market a little better I have learned that there is no value for my customer in an attractive website that tells them how brilliant I am.  What actually delivers value for my clients is providing information or content that can help them make more meaningful decisions or improve their business or personal performance in some small way.  Yes usability is important, but that is something that I can improve over time with enough feedback from the marketplace.  Again my experience informs me that my customers value content quality content over sexy graphics.

Lessons learned?

Now can I honestly say that I became enlightened overnight? No; I have made many mistakes overtime and repeated some of them because I wanted to be sure they were mistakes in the first place.  And who knows: maybe this latest product in my evolution will also tank, but at least this time I know I have done something different and changed my behaviours and attitudes in the meantime.  For this at least I can feel satisfied and continue to be informed by reality rather than my own biases and patterns.