Bas Vode has developped a small test for teams he was coaching at Nokia, it has been called Nokia Test.
In 2008, Jeff Sutherland improved it in adding a scoring system. In its CSM courses, he called it "Scrum But" test.
It is that version that we propose you to pass.

This is the second of several posts in which I’d like to share some of the things we learned throughout more than 14 sprints of Agile development using Scrum. Some of them might appear as open doors, but I wish I knew or thought about those before I started that project. Just by looking back at the mistakes a team of 10 made in a period of 12 months, they apparently aren’t that obvious. So after having discussed requirements management, let’s talk about the sprint planning.

Met de projectmanagementmethode Scrum proberen bedrijven snel en efficiënt IT-systemen te bouwen. De methode werkt met veel tussenversies om de kwaliteit te kunnen garanderen. Maar hoe staat het met de kosten? Is de methode te combineren met fixed-pricecontracten? Het lijkt onmogelijk, zeggen Rini van Solingen en Eelco Rustenburg, maar in de praktijk gaan Scrum en fixed price prima samen.

This book aims to give you a head start by providing a detailed down-to-earth account of how one Swedish company implemented Scrum and XP with a team of approximately 40 people and how they continuously improved their process over a year's time.

The daily stand-up meeting (also known as a "daily scrum", a "daily huddle", a "morning roll-call", etc.) is simple to describe: the whole team meets every day for a quick status update. We stand up to keep the meeting short. That's it. But this short definition does not really tell you the subtle details that distinguish a good stand-up from a bad one.

Given the apparent simplicity of stand-ups, I was quite surprised the first time I saw one that wasn't working. It was immediately obvious to me what was wrong but I realised that it was not obvious to the team. I realised that my team was not aware of the underlying principles and details that would allowed them to diagnose and solve problems with stand-ups.

People who have experienced good stand-ups will generally know what can be done when things aren't working well. For novice stand-up attendees, when things go wrong, it is much less likely that they'll figure out what to do. One way to approach this issue is to claim that it's all a matter of tacit knowledge and novices just need to attend more well-run stand-ups. I believe, however, that it's much more likely that given no assistance, novices will simply abandon the practice of daily stand-ups. This would be unfortunate since well-run stand-ups add significant value to projects.

This is my attempt to communicate some of the previously tacit knowledge on the benefits and consequences of common practices for daily stand-ups. These patterns of daily stand-up meetings are intended to help new practitioners as well as remind experienced practitioners of what they might already know in their gut.

The hype has settled down a bit over these past five years. Many games developed using agile practices, mainly those in the Scrum framework, have shipped. There has been more than enough time to understand how much agile can really help a game team. It's time to look at what is emerging from agile game development teams.