back to notes

Nokia Test as updated by Citrix and Scrum Inc

Nokia Test as updated by Citrix and Scrum Inc. v. 2013-7-31
• As an agile citizen, I can assess a team’s behavior and compare it to current Scrum best practices, so I can consider changes that might increase productivity.

Instructions
• Each person on a team should have a piece of paper
• There are 10 assessments
• Each assessment has a score from 0 to 10
• In each assessment, sum the “Acceptance Tests” scores that pass.
• Total score will range from 0 to 100
• Average the scores for team members to get the team score

Assessment 1: Iteration
As a team, before we commit to a Sprint, we know its duration, so we deliver better rhythmic, synchronized value.
Acceptance Tests:
Variable, 4 < duration ≤ 6 weeks: 2
Variable, duration ≤ 4 weeks: 4
Constant for last 3 iterations, duration = 1 month: 5
Constant for last 3 iterations, duration = 4 weeks: 6
Constant for last 3 iterations, duration = 3 weeks: 8
Constant for last 3 iterations, duration ≤ 2 weeks: 10

Assessment 2: In-Sprint Testing
As a team, we take joint responsibility for all testing, so our Sprint product has sufficient quality to be immediately deployable.
Acceptance tests (sum):
Team creates some unit tests in-sprint: 1
Team creates unit tests for each story in-sprint: 1
Team tests each story prior to Sprint Review: 2
Team tests each story immediately after coding: 2
Team automates feature tests for each new story: 2
Build system packages, deploys to stage or live, and runs all automated feature tests at least every 24 hours: 2

Assessment 3: Sprint Stories
As a team, we commit to work only when backlog items conform to a Definition of Ready, so we generate business value fast.
Acceptance Tests (sum):
Sprint requirements are documented: 1
Requirements are independent, well-prioritized stories: 1
Stories start with this: “As a <stakeholder>, I can <do something>, so <business gains value>”: 2
Stories have externally verifiable acceptance tests: 2
Team has a written, enforced Story Definition of Ready: 2
Team has a written, enforced Story Definition of Done: 2

Assessment 4: Product Owner
As a team, a single Product Owner helps the team understand and prioritize value, so we generate profits long-term.
Acceptance tests (sum):
A single external person (PO) prioritizes work: 2
PO interrupts team work only during Scrum meetings: 2
PO attends all Planning, Grooming, Review and most Standups: 2
PO creates a product backlog, with stories estimated by the team before Sprint Planning: 1
PO maintains a velocity-aware release roadmap: 1
PO motivates team to reduce technical debt: 2

Assessment 5: Product Backlog
As a team, we have a value-ranked backlog, so we can focus on work that will generate the most business value for the least effort.
Acceptance Tests (sum):
Team serves multiple prioritized Product Backlogs: 1
Team serves a single prioritized Product Backlog: 2
PO regularly discusses release burndown with team, and adjusts backlog priorities based on historic velocity: 1
Stories more than 3 months out trend larger in effort: 1
Team can explain the ROI of each story: 1
PO assesses value (NPV, buy-a-feature) to rank stories: 2
PO prioritizes cheap prototypes to test value early: 2

Assessment 6: Estimation
As a team, our estimates are largely free of statistical bias, so stakeholders can reley on release forecasts and make more money.
Acceptance Tests (sum):
Team agrees to estimates before committing: 1
PO, SM and non-developers do not supply estimates: 1
Team carefully avoids anchor bias before estimation: 1
Representatives or actual team creates poker estimates: 1
Actual team creates poker estimates: 2
Teams use reference stories to make estimates: 2
Actual velocity is < +/-20% of estimated velocity: 2

Assessment 7: Sprint Burndown
As a team, we know our progress toward completion of backlog items, so members can help with high-priority work-in-progress.
Acceptance Tests (sum):
Burndown exists, team knows where it is: 1
Team reviews, adjusts tasks and burndown daily: 1
Tasks have hour or point estimates estimates (or team makes tasks about the same size): 2
Tasks burn down only after whole task is done: 2
Stories burn down (no tasking) after whole story is done: 2
All team members know team’s historic Velocity: 1
Team commits to sprint backlog at or below Velocity:1

Assessment 8: Retrospection
As a team, we review our processes, so we can sustainably improve productivity.
Acceptance Tests (sum):
Team conducts retrospectives at least every 2 months: 2
Team conducts retrospectives after each Sprint: 2
Team limits retrospective participation to team and SM.
Team optionally invites PO and others or uninvites SM: 2
Team uses sticky-notes/other tools to ensure all members participate and tracks followup: 2
Team puts top process improvement in the backlog for next sprint with acceptance tests: 2

Assessment 9: Scrum Master
As a team, the Scrum Master (SM) competently enforces process, removes impediments, and provides transparency, so we can focus well.
Acceptance Tests (sum):
SM understands Scrum and agile concepts deeply: 2
SM performs no tasks in the Sprint: 1
SM enforces rules established by the team: 1
SM sees impediments early, and handles for the team: 2
SM maintains and uses a prioritized impediments list: 1
SM makes team’s progress transparent to outsiders: 2
SM communicates well with team, other teams, managers, stakeholders and PO: 1

Assessment 10: Team
As a team, we work together effectively to releasing our software, so we can get software to users earlier and adapt rapidly.
Acceptance tests (sum): 3 ≤ team size without counting SM or PO ≤ 7: 2
Team members volunteer (are not assigned) to tasks: 2
At least 2 members can independently finish each task: 2
Team collectively commits to Sprint goal and backlog: 1
Team collectively fights impediments in-sprint: 1
Team reduces technical debt every sprint: 2