I have started using Scrum for various purposes: It has inspired the way software is developed at my current employer. I use it to organize a students' project at university. In addition we are using it at home to get all personal tasks (preparing breakfast, doing the laundry, meeting with friends...) in line for each week.
Constantly looking for ways to evaluate, refine and improve work - I am also looking for ideas on how to evaluate which aspects of the Scrum implementation can actually be improved. One pretty common way to do this evaluation is to do the so-called "Nokia-Test"
. A set of questions on the project management that gives a possibility to judge your implementation of Scrum. As an example lets just have a closer look at our "Scrum Housework" implementation.
Question 1 - Iterations
- No iterations - 0
- Interations > 6 weeks - 1
- Variable length < 6 weeks - 2
- Fixed iteration length 6 weeks - 3
- Fixed iteration length 5 weeks - 4
- Fixed iteration 4 weeks or less - 10
Currently we are doing one week iterations - planning ahead for longer just seems impossible, except for events like going to conferences or regular birthdays. So that would be 10 points for iterations.
Question 2 - Testing within the Sprint
- No dedicated QA - 0
- Unit tested - 1
- Feature tested - 5
- Features tested as soon as completed - 7
- Software passes acceptance testing - 8
- Software is deployed - 10
Hmm. Admittedly there is no real testing in place except for smoke testing for stuff like emptying the dish washer.
Question 3 - Agile Specification
- No requirements - 0
- Big requirements documents - 1
- Poor user stories - 4
- Good requirements - 5
- Good user stories - 7
- Just enough, just in time specifications - 8
- Good user stories tied to specifications as needed - 10
We do not have big documents describing how to setup the christmas tree. But at the beginning of each sprint there is a set of user stories, if needed with acceptance criteria specified. So something like "Tidy up computer desk" would be augmented by the information: "To the extend that there are no items except for the laptop on the desk afterwards and the desk was dusted". That might probably make a 10.
Question 4 - Product Owner
- No Product Owner - 0
- Product Owner who doesn’t understand Scrum - 1
- Product Owner who disrupts team - 2
- Product Owner not involved with team - 2
- Product owner with clear product backlog estimated by team before Sprint Planning meeting (READY) - 5
- Product owner with release roadmap with dates based on team velocity - 8
- Product owner who motivates team - 10
We are both familiar with Scrum. However, due to the nature of the tasks and due to lack of people in the loop we are exchanging the role of the product owner regularly. We are still missing a product backlog - currently it is loosely defined as a pile of post-it notes with estimates put beside each item that define its complexity. So I would give some 3 points on that one.
Question 5 - Product Backlog
- No Product Backlog - 0
- Multiple Product Backlogs - 1
- Single Product Backlog - 3
- Product Backlog clearly specified and prioritized by ROI before Sprint Planning (READY) - 5
- Product Owner has release burndown with release date based on velocity - 7
- Product Owner can measure ROI based on real revenue, cost per story point, or other metrics - 10
We only have one product backlog though it is very informal. So that would make 2 points.
Question 6 - Estimates
- Product Backlog not estimated - 0
- Estimates not produced by team - 1
- Estimates not produced by planning poker - 5
- Estimates produced by planning poker by team - 8
- Estimate error < 10% - 10
Naturally those doing the tasks are those producing the estimates. Thanks to Agile42 in Berlin we now even have a set of planning poker cards: Yeah! That makes 8 points. Just as an example: Getting returnable bottles back to the shop makes for 8 complexity points, going to cinema are 16 just like storing the christmas decoration back in it's boxes, preparing breakfast is just about 3 points ;)
Question 7 - Sprint Burndown Chart
- No burndown chart - 0
- Burndown chart not updated by team - 1
- Burndown chart in hours/days not accounting for work in progress (partial tasks burn down) - 2
- Burndown chart only burns down when task in done (TrackDone pattern) - 4
- Burndown only burns down when story is done - 5
- Add 3 points if team knows velocity
- Add two point if Product Owner release plan based on known velocity
Our we do have whiteboard with post-it notes on them that are checked out and moved to done as soon as they are done - there is no arguing about the laundry being done before it is cleaned, dried, ironed and back to the closet. ;) So that would make for 5 points. In addition we know our velocity, which would make another 3 points:
Naturally we are pretty capable of telling what can reasonably be expected to be done within the coming sprints. That might add another 2 points for the release being based on that velocity.
Question 8 - Team Disruption
- Manager or Project Leader disrupts team - 0
- Product Owner disrupts team - 1
- Managers, Project Leaders or Team leaders telling people what to do - 3
- Have Project Leader and Scrum roles - 5
- No one disrupting team, only Scrum roles - 10
There are events and people interrupting running sprints: Say, NoSQL meetups that are planned spontaneously or new articles that get written and printed within less than a week. But usually these events are rather seldom and are kept to a minimum due to the short sprint length. So that might make for 3 points.
Question 9 - Team
- Tasks assigned to individuals during Sprint Planning – 0
- Team members do not have any overlap in their area of expertise – 0
- No emergent leadership - one or more team members designated as a directive authority -1
- Team does not have the necessary competency - 2
- Team commits collectively to Sprint goal and backlog - 7
- Team members collectively fight impediments during the sprint - 9
- Team is in hyperproductive state - 10
Currently we are in a state where we have identified and started emerging impediments - declining tasks that cannot reasonably be done within the given timeframe, getting a real product backlog up, tracking even minor tasks like writing e-mails to organize the Apache Hadoop Get Together. So that makes for 9 points.
In total that makes for 54 points (excuse for computing incorrectly: It is 23:34, I am a little tired but cannot sleep due to caffeine). How does your team score on the Nokia test?