Category Archives: Scrum for Business

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.

 

 

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