Step 10: Review, Reflect, Repeat

So you’ve got your backlog in order, estimated your backlog, clarified your requirements, planned your sprint and created a collaborative workspace.

You’ve sprinted to achieve your sprint goals, run daily stand-up meetings and tracked progress with a daily burndown chart.

Now you’ve come to the end of your Sprint and finished when you said you would. All that’s left to do now, is Review, Reflect and Repeat…

Sprint Review

At the end of the Sprint, hold a Sprint Review meeting. Invite the whole team. Invite all the key business stakeholders. Invite senior stakeholders including executives where appropriate. The more interested parties the better!

Review what was delivered in the Sprint. Demo the software. Whether it’s complete, working software prior to a release, or work-in-progress in a long-running multi-Sprint project, demo what has been completed in the Sprint. Let team members demo the areas they have worked on.

The purpose of the Sprint Review is three-fold:

  1. It allows team members to show what they’ve achieved and demonstrate their contribution to the product.
  2. It allows all key stakeholders to see what’s been done, and provide valuable feedback on a regular basis, while there’s still time to take it on board.
  3. It helps the team to stay focused on the deadline of the Sprint - no-one wants to show up at the Sprint Review with nothing useful to demo.

Sprint Retrospective

Following the Sprint Review, hold a Sprint Retrospective meeting. Invite the whole team. Invite the Product Owner. But this meeting is not for the wider stakeholders. Typically it might follow on immediately from the Sprint Review.

The purpose of the Sprint Retrospective is to reflect on how things went during the Sprint. It’s a chance for the team to discuss the Sprint and consider how they could improve things.

Together the team should:

  • Review the final Burndown Chart. How did it go? Did the team deliver what they committed to at the start of the Sprint? Note the outstanding hours in a spreadsheet so the team’s success rate can be plotted on a graph over time, to see if it’s getting better or worse. This is a tool for the team to gauge its progress by. It’s not a stick for management.
  • Review the team’s Velocity? Velocity is the number of points estimated on the original product backlog, for the items *completed* in the Sprint. Only items 100% complete and delivered, signed off, in the software count in the team’s Velocity. Again, plot this on a graph so the team’s Velocity can be tracked over time, so the team can see if it’s delivering more or less as time goes by. Velocity will gradually settle around a norm, and can then be used in Sprint Planning as a gauge for how much the team could realistically achieve, based on their track record.
  • Discuss what went well? (try to make sure it’s repeated next time)
  • Discuss what could have gone better? (try to understand why)
  • Decide what the team will do differently in the next Sprint? (try to pick a few actionable points that can actually be done differently immediately in the next Sprint)

This is a continuous learning process.

Traditional project management methods, such as PRINCE2, also encourage continuous learning, through the production of a lessons learnt report on closure of the project.

The trouble with this is people don’t always remember enough by the end of a long project. Or perhaps there is so much to reflect on at the end of a large project, that there are too many things to consider and the result just isn’t actionable. And often on completion of a traditional project, the project team disperses onto other projects or back to where they came from, preventing them from applying their learnings as a team.

In Scrum agile development, like the product development itself, the learning is in small, bite-sized chunks. Little but often. While there is still time for the feedback to have a positive impact on the project.

Repeat

The team is now armed with valuable information – about the product, about their performance, and about some of the impediments in their environment, e.g:

  • How the software looked after the last Sprint.
  • Feedback about the product developed so far.
  • To what extent the team was able to deliver what it committed to in Sprint Planning.
  • The team’s Velocity and what is achievable in a typical iteration.
  • What went well.
  • What didn’t go so well.
  • What will be done differently going forward.

All that’s left for the team to do now, is repeat the process, with the greater knowledge gained from above.

Realistically it takes 3 or 4 Sprints for the team to get into a rhythm. To apply the improvements and get used to the process. For the Velocity to settle around a norm. And for the team to gel…

That’s all folks!

So that’s it! That’s basically Scrum, and how you can implement it in 10 easy steps.

Of course, in reality, the steps aren’t all that easy. The steps involve humans. And software development. Tricky combination!

Nevertheless, the Scrum process is inherently easy. And depending on your situation – certainly in my experience – Scrum and agile development can help your success rate in many many ways.

Kelly.

See also:
How to implement Scrum in 10 easy steps:
Step #1: Get your backlog in order!
Step #2: How to estimate your product backlog
Step #3: Sprint Planning/clarify requirements
Step #4: Sprint Planning/estimate tasks
Step #5: Create a collaborative workspace
Step #6: Sprint!
Step #7: Stand up and be counted!
Step #8: Track progress with a daily burndown chart
Step #9: Finish when you said you would
Step #10: Review, reflect, repeat…

‘Implementing Scrum’ PowerPoint Presentation

10 Key Principles of Agile Software Development

8 Responses to “Step 10: Review, Reflect, Repeat”

  1. Vladimir Levin says:

    Hi Kelly,

    I want first to congratulate you on getting through all the steps! I don’t know if you’ve envisaged using these steps as the core of a “real” i.e. “dead trees” book, but I think it could work, especially combined with your real-world observations about what has and has not worked on actual projects.

    I don’t know if this is part of the authentic scrum canon, but regarding the product backlog this is something I recommend:

    Since the backlog is used to produce an initial estimate of how long/how costly a project will be, I like to set limits on the size of a backlog item. Items that are coming up soon, I try to limit to a 1 week max estimate size – that’s about the size of an XP story. Items further down in priority, I try to keep to a max of 1 month – the size of a single scrum iteration (or alternatively to whatever the scrum iteration length happens to be). If something looks bigger than that, I try to work with the business to break it up into smaller units.

    I also use the concept of the “red line” which marks anything that falls below the amount of time that is currently budgeted for the project. Items below the red line can be as general as we like since we won’t be getting to them any time soon. But if the customer moves one such item above the line after a given iteration, then again, a better first order estimate needs to be made.

    One last thing, I’ve always had a hard time coming up with fake product and sprint backlogs (not allowed to publish ones from real projects), along with a sprint curve – they always end up looking rather engineered. If you are able to come up with a real one that you can publish or something very realistic, I think that would be helpful!

  2. Anonymous says:

    I agree that it would be very helpful to have real Product Backlog and Sprint Backlogs available as examples.

  3. Kelly Waters says:

    One of the readers of my blog has kindly posted examples of a product backlog and sprint backlog.

    See here:

    http://www.agile-software-development.com/2008/07/example-product-backlog-sprint-backlog.html

    Kelly.

  4. Renu says:

    Hello,
    Nice article.
    How should one go about planning for user-testing/deployment etc.,? We typically release after each sprint iteration and one person is left behind to co-ordinate user testing & release, while the rest get on with next iteration. (this is for a BAU project)

  5. Anonymous says:

    This was an awesome series! Thanks so much for writing this.

  6. Anonymous says:

    Great article series. Best resource on the internet about Scrum. Thank you.

  7. Nadeem Khan says:

    What an outstanding effort! Hats off to you folk for making agile development a piece of cake for every beginner, cheers!

  8. Paul Elia says:

    You have written a truly wonderful and brief series about Scrum! I have read full-sized books that contained less valuable content than this series.

    I was especially impressed with your writing and content for step 2 regarding how to estimate your product backlog. This is the step I often see done wrong in the name of Scrum. People seem to gravitate towards estimating product backlog items in terms of TIME but you are so right — it should be done as a measure of COMPLEXITY perhaps with a dash of Business Value. Only at the last moment in planning should tasks be estimated in terms of time.

    My advice to readers who are new to Scrum, for what it’s worth: Take Kelly’s advice and try it for yourself as-presented before you knock any of it. It may be tempting to do things differently especially if you have used other techniques with success in the past but you will be well served to try Scrum this way first.

Leave a Reply

What is 4 + 1 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”

PETER SILVA-JANKOWSKI
IPC MEDIA

“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”

LUKE SHARKEY /STRATEGY & IMPLEMENTATION LEADER
SUNCORP

“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”

GILES BENTLEY, DEVELOPMENT & OPERATIONS DIRECTOR
TIME INC

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA

“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”

GINA MILLARD
GLASS'S INFORMATION SERVICES

“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”

ANDY JEFFRIES/TECHNICAL LEAD
IPC MEDIA

“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”

HANNAH JOYCE
GLASS'S INFORMATION SERVICES

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”

BRUCE WEIR/EGM
SUNCORP

“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”

BEATRIZ MONTOYA/CONSUMER MARKETING DIRECTOR
IPC MEDIA

“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”

PETER THATCHER, SENIOR ACCOUNT DIRECTOR
ThoughtWorks

“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”

JULIE PEEL
GLASS'S INFORMATION SERVICES