Nokia Banner

The Nokia Test, extended with scoring by Jeff Sutherland


History


Nokia has several hundred Scrum Teams. In 2005 Bas Vodde, agile pioneer and coach within Nokia Networks, started to develop a test so that they could quickly asses the status of any team claiming to do iterative and agile software development. 2007 he tuned the test to a simple 8 question yes/no test including Scrum practices. The people at Nokia say that test saved them so much pain and confusion over so many years, they would not be without it.

In 2008, Scrum co-creator Jeff Sutherland extended the pass/no pass test with a scoring system, giving you a rating from 0-10. In 2009 he added a Team question to the test. Jeff Sutherland has been involved in creating some of the most productive and profitable software development companies ever. Perhaps most notably with PatientKeeper where he was the CTO. Currently he works with openview venture partners to help investors make money by only investing in companies with state of the art software development capabilities. So, his opinion on what makes a good Scrum is well worth listening to.

If you want to see how your Scrum implementation measures up to Nokia & Jeff Sutherland's standards, just fill out the form below and click submit!


Select the answer to the question by clicking in the circle in front of the best choice.

  1. Describe your iterations
    We do not use iterations
    Iteration length is > 6 weeks
    Iteration length is variable but < 6 weeks
    Fixed iteration length 6 weeks
    Fixed iteration length 5 weeks
    Fixed iteration length 4 weeks or less


  2. Describe your testing

    We do not have any dedicated QA
    At the end of an iteration software is unit tested
    At the end of an iteration software is feature tested
    Features are tested as soon as they are completed (during iteration)
    At the end of an iteration software passes acceptance testing
    At the end of an iteration software has been deployed at customer


  3. Describe your requirements at the time an iteration starts

    We do not have any requirements
    We have a big requirement documents
    We have poor user stories
    We have good requirements
    We have good user stories
    We have just enough, just in time specifications
    We have good user stories tied to specifications as needed


  4. What about your Product Owner?

    We have no Product Owner
    We have a Product Owner that do not understand Scrum
    We have a Product Owner who disrupts Team during iterations
    We have a Product Owner who is not involved with Team
    We have a Product Owner with a clear Product Backlog estimated by team before Sprint Planning meeting
    We have a Product Owner with a release roadmap with dates based on Team velocity
    We have a Product Owner who motivates Team


  5. What about your Product Backlog?

    We have no Product Backlog
    We have multiple Produck Backlogs
    We have a single Product Backlog
    The Product Backlog is clearly specified and prioritized by ROI before Sprint Planning
    Product Owner has a release plan based on product backlog
    Product Owner can measure ROI based on real revenue, cost per story point, or other metrics


  6. How about your estimates?

    The Product Backlog is not estimated
    The Product Backlog has estimates not produced by Team
    The Product Backlog has estimates not produced by planning poker
    The Product Backlog has estimates produced by planning poker by Team
    Our estimate error is < 10%


  7. How about your burndown charts?

    We have no burndown charts
    The sprint burndown chart is not updated by the Team
    The sprint burndown chart burns down also for partially completed tasks.
    The sprint burndown chart only burns down when a task is done
    The sprint burndown chart only burns down when a story is done

    Does the Team know its velocity? Yes No

    Is the Product Owner release plan based on known velocity? Yes No

  8. Team disruption

    There are Managers or Project Leaders that disrupt Team during iteration
    The Product Owner disrupt Team during iteration
    Manager, Project Leaders or Team Leaders are telling people what to do
    We have both Project Leader and Scrum roles
    No one is disrupting team, we have only Scrum roles

  9. Team

    Tasks are assigned to individuals during Sprint Planning
    Team members do not have any overlap in their area of expertise
    No emergent leadership - one or more team members designated as a directive authority
    Team does not have the necessary competency
    Team commits collectively to Sprint goal and backlog
    Team members collectively fight impediments during the sprint
    Team is in hyperproductive state


  10. Some optional information for our Nokia Test survey:

    How big is your organisation? 1-24 25-99 100-499 500-4999 > 5000

    Where are you situated?



Back to top