So You Think You Can Scrum?

Are you really doing Scrum? Or is it more Scrum-like, Scrum-but or semi-Scrum. To find out, try to pass the Nokia test that was developed by Bas Vodde:

1. Iteration must be time boxed to less than 4 weeks.
2. Software features must be tested and working at end of each iteration.
3. Iteration must start before specification is complete.
4. You know who the product owner is.
5. Product backlog is prioritized by business value.
6. Product backlog has estimates done by team.
7. Team knows their velocity.
8. There are no managers disrupting the work.
9. Team commits collectively to Spring goals and fights impediments.

Jeff Sutherland later modified this test and added a scoring system as explained here.

Beyond The Manifesto

It all started out with the Agile Manifesto of valuing:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

Then there are the 12 principles of the Agile Manifesto covering continuous and frequent delivery at a constant pace, embracing change, team work, self organization, trust, craftsmanship, and retrospection:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
•  Business people and developers must work together daily throughout the project.
•  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
•  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This was followed by the Declaration of Interdependence:

The Art of Storytelling

 In User Stories Applied: For Agile Software Development, Mike Cohn defines user stories as simple, clear and short descriptions of customer valued functionality. They are composed of three aspects:

1. A brief description of the story used for planning.

2. Conversations of the story that serve to flesh out the details.

3. Acceptance tests to determine when a story is complete.


User stories offer a number of advantages over requirements documents and use cases. These include:

1. Emphasis on verbal rather than written communication.

2. Encourage deferring details until you have a better understanding about what you really need.

3. Provide the right size for planning.

4. Are comprehensible by customers and developers.

5. Work for iterative development.


Good user stories should follow the INVEST principle:

1. Independent: Stories should not be interdependent as this might lead to prioritization and planning problems.

2. Negotiable: A story should be brief and it is not a detailed contract. It should encourage conversation and negotiation between the customer and the developers.

3. Valuable: A story should provide value to the customer or the user.

4. Estimatable: Developers need to be able to estimate a story. It should be written in such a way that the developers can understand it and have an idea of how to implement it.

5. Small: Not too big, not too small, but just right!

6. Testable: Stories should be testable in order to verify that a story is complete.


Additionally, good user stories follow these guidelines:

1. Start with Goal Stories: For each user role, identify the top priority goal for that user.

2. Use Templates:

• a. Use the following template to incorporate User Role and Value into a story: - As a [type of user], I can [goal] so that [reason].

• b. Use this template for acceptance tests: Given [context] And [some context] When [event] Then [outcome] And [another outcome].

3. Slice Vertically: Stories should represent some level of end to end functionality. This reduces overall risk and delivers some value to the customer.

4. Annotate Stories with any constraints.

5. Keep the UI Out for as long as possible: This avoids mixing requirements with a specific solution.

It is important to remember that the main purpose of a story is to act as a reminder and encourage conversation to flush out details the closer we are to implementing a story. Also, not everything needs to be a story. Some aspects of the system might be expressed better using different formats.