Tag Archives: scrum

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.

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

Scrum Ceremonies: Retrospective

The retrospective is also commonly referred to as lessons learned.  Which in itself is an interesting turn of phrase, because my experience tells me lessons are not really learned until we have changed our thoughts or behaviour in some way and usually the experiences have to be repeated a number of times in different contexts before the lessons are finally learned … but I’ll not labour this point, except to make a suggestion at the end which I hope adds extra value to the process.

The  Retrospective takes place after the sprint review (aka show and tell), so it is the final one of the sprint ceremonies to take place during a sprint. It should take only an hour to complete, although the team may decide that they would like longer because of some particular issues that may have arisen during the sprint.

As with all the other ceremonies all the team is present with the purpose of reviewing how the team performed during the last sprint.  It is an important but necessary point to note that the Retrospective delivers greatest benefit when it is carried out at the end of the sprint.  I know of some teams that decided to have their retrospective some time after the sprint was completed.  At that point, even though it was only a few days into their new sprint, the teams had already forgotten about what was important for them in the previous sprint and they were edgy and wanted to get back to the important work of this sprint.  Delaying having the Retrospective in my view is a big mistake and can be costly as a lot of important information will be forgotten.

Getting of to the right start

It should be noted that if the team or team members are new to this activity of retrospecting then there may be some defensive behaviours that may present themselves.  It may be a good idea to have an independent and skilled facilitator come and run the session so that people understand the need for this process and work together for its successful conclusion.  The Retrospective is about learning and very little learning is done in unsafe environment where the participants feel that they will be verbally attacked by their co-workers.  So setting the right environment at the start is important.  I am happy to provide some suggestions if you would like to know more about how to create the right environment.  Just leave a response in the box below and I will answer it within 48 hours – how Agile is that?

How do we run a retrospective

There are many different style and flavours in which a retrospective can be run and it largely depends on what has happened in the previous sprint as to how the team leader will facilitate the session.  My personal preference is to have plenty of wall space available with flip charts and post it notes that capture information along the following two themes:

  • What went well in this sprint?
  • What didn’t go so well in this sprint?

The team should be allowed some time to reflect on these two themes and write a post-it note for each event that was of importance for them and place this note on the wall.  Depending on team size and how “positively” or “negatively” eventful  the previous sprint was will determine the number of issues that the team may want to reflect on in more detail.  If there are too many issues to discuss in the retrospective the team can vote on what is most important to them.

So depending on what the team chooses to talk about, they will invariably seek to answer these questions.

  • What should we start doing in the next sprint?
  • What should we stop doing in the next sprint?
  • What should we change in the next sprint?

These are important questions that are aimed at behaviour change that will improve the functioning of the group.  This little activity I have seen pay huge dividends in the smallest of teams as they seek to improve with every passing sprint.

Committing to change is permission to change

So answering those questions is important but the most important aspect of the retrospective is the agreement of the attendees to follow through on the actions afterwards.  What I find is that if we find people are passionate about changing something, they will usually follow through on making this change happen.  To that end my approach is to build passion, energy and enthusiasm around the change with the group while they are in the room.  To wait until after they have left is too late, the moment will have passed. So I ask for a volunteer to champion that change for the duration of the next sprints.  I have never yet had a situation where people haven’t volunteered.  But finding the volunteer isn’t enough, what I then ask the volunteer to do is to ask the group for permission to champion the change.  Now of course the rest of the team would like to know how are they going to go about championing the change and this is where the team can get creative.  Things like: paying a fine if anyone is “caught” doing one of the STOP behaviours, putting a picture of a team player who is most actively carrying out the changes.  Two great group motivators are being recognised by the group or being alienated by the group so these can be used to great effect, but hopefully in an ethical and compassionate way.

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

Scrum Ceremonies: Sprint Planning

What’s a Sprint?

Firstly a definition for you:  A sprint is defined as a set period of time where the team works to achieve goals within that time period.  If you like, a rugby game consists of two sprints, each of 40 minutes duration.  In business we need a little longer to achieve our goals and so we may decide to split a 3 month project into 12 two week sprints.  (Sprints are also referred to as timeboxes or iterations, although timeboxes as defined in DSDM have more structure to them.) Sprints can also be anything up to 4-6 weeks duration but I recommend shorter sprint times as it allows for more feedback on the evolution of our goals and will often provide the very necessary course correction to get us back on track.

Sprint Planning

Each sprint is started with a sprint planning session.  This session should take no longer than two hours and will have all team members present.  The purpose of the sprint planning session is to:

  • clarify the goal for the duration of the sprint
  • identify all the tasks in order to achieve the goal
  • estimate the time taken for each task
  • get the team’s commitment for the achievement of the goal

The ultimate outcome of the session is for the team to have agreed all the tasks that are to be carried out during the next sprint.  The important thing here is that the individuals make a commitment to working on their tasks in order to achieve the teams goal.

Hows this different to traditional planning

Now you might ask how is this different to any other project planning session?  Well it is different in a few ways.  Firstly all the team are present.  Often what tends to happen on other projects is that the project manager will seek out the expertise of one or two individuals on the project and ask them how long all the tasks will take.  The PM then goes back to his desk and neatly compiles his Gantt chart with a plan THAT SHALL NOT MOVE. Often the PM will go back and cajole her experts into giving smaller estimates because the end date on the Gantt chart (that which must be obeyed) does not align with the customer expectation.  Therefore some negotiation of task duration ensues.  This is often a mistake because rather than accept the estimate and negotiate with the customer (who is always right – or are they) it is easier to persuade, cajole or even bully team members into giving the “right” numbers.

Everyone counts

By having all the team present in the planning session we open everyone up to the collective wisdom of the team and as such the planning session becomes a learning session for the more junior members of the team.  Each item or requirement that is to be delivered if broken down into its constituent tasks; each of the tasks is then estimated by the person who will be carrying out that particular piece of work.  Note that this is an important part of the process, if the person doing the work estimates how long its going to take there is no reason why they can’t commit to that piece of work being done within the agreed timeframe.  Now of course there can be some challenging of the numbers because some people may achieve the work in half the estimated time.  This is where the team leader can act as a facilitator these sessions to make sure that challenges aren’t seen as attacks.  When an estimate is challenged this should be seen as an opportunity for learning.  It could be that it is a junior team member who might not be aware of a more efficient solution to the meeting of the requirement. In which case a more seasoned member will be able to advise a more appropriate course of action.

Another way in which this planning is different to traditional planning is that not all of the work is planned in detail up front.  The detailed planning only takes place for the next sprint.  We might have a rough idea of what may happen in future sprints, but we don’t detail that until just before the sprint starts.  Notice the emphasis on what  may happen; this is how we are able to take change and uncertainty into account.  Detailed planning requires much time and investment to do it properly, so Agile businesses do just enough detail up front planning that is necessary.  We will speak more about this in later posts on this blog.

Adding up the time

An important part of the process is to having keep track of individual and team commitments to time.  Before the meeting starts the team leader will ask the members to provide them with the amount of time they can commit to project work in this sprint.    This allows the team leader to set up spreadsheet in advance with all the names of the team members and their time availability. During the sprint planning each person volunteers themselves to do certain tasks and estimates how long it will take to complete it.  This time is subtracted from what they have committed to.  This allows us to make sure that each person on the team commits only as much time as they have available.  As soon as all team members time is committed some time is taken to ensure that finishing these tasks will result in the Sprint Goal being achieved.

Getting the commitment

Once the team have agreed the goals, tasks and estimates for them the team leader will ask the team if they are happy to now commit to the goal of sprint.  It is important that the team leader gets a sense of the energy in room and to make sure that the members are not just saying that they will commit.  If the leader senses or picks up that something is wrong he should address it in the room before the Sprint Planning is completed.  Otherwise what is left unsaid could fester an impair the progress of the team in the future.

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

Scrum Ceremonies: The Daily Stand-Up

The activities or ceremonies used within Scrum are currently being used by business teams around the world who don’t have a technology bias.  This is because these practices add great value to the teams using them, they are simple to adopt and improve the communication between teams.  Here is a short summary of these Scrum ceremonies.  If you would like more information on any of these then just leave a reply in the box below.

Daily Stand-Up

As the name suggests this is a daily meeting, that is preferably held with all members standing up.  The purpose of the daily stand-up is to communicate the progress being made (or not) by individuals to the rest of the team.  The meeting should take less than 15 minutes depending on the number of people in the team.

The agenda of this meeting is as follows:  each team member answers the following three questions:

  • What did I do yesterday?
  • What do I intend to do today?
  • What’s blocking my progress?

The benefits that the daily stand-up brings are as follows:

  • To communicate what is going on
  • It helps the team to start the day well
  • To helps the team to focus on the right things
  • To reinforce team-spirit and collaboration

This is one simple practice that every team can initiate and add their own flavour to it.  However if people attending the meeting think its a waste of time, or people don’t attend or are late, the team leader will need to address these issues.  Very often these issues are not a problem of the daily stand-up but might be more deep rooted in the dynamics and well being of the team.  I will discuss this in greater detail in a later blog post.

This is also a most effective activity if you have a number of remote workers on your team as it gives them a chance to “meet” with the rest of the team at least once a day.  But do invest in decent equipment or tools such as skype and webcams.  If you have ever been on a standup call with remote workers in India who are huddled around a phone, you will know what I mean: the office noise and other distractions make listening to what people are saying a bit of a chore and can discourage people from attending or paying attention.

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