SprintPlanner.com

The Agile Maturity Questionnaire

Version: 2019 July

Take a few minutes to individually think about each of these items and score them on a scale of one to ten. Where one means "not true at all" and ten means "absolutely true".

Get together with your team and discuss the scores.

Fundamentals

  1. During the sprint our team is more focused on the amount of on subtasks and stories can be completed by the end of the sprint, versus the value of the (potentially deployable) working software that is delivered.

  2. We have and understanding of the "final" application we're building towards, AND also have clear potentially deployable intermediate applications.

  3. Each team member has clearly defined roles/responsibilities. (e.g. QA does testing. devs do development, etc)

  4. The majority of our stories are fit for production deployment when they're moved to done. (i.e. "done" stories don't need to wait for other stories to be complete before they can be deployed.)

  5. At the start of each sprint, the story points represent only the work to be done during this current sprint. (i.e. doesn't include work effort that was done in a previous sprint, or work to be done in future sprints)

  6. What we present during sprint review, could be handed to the stakeholders (with some basic instructions) for them to play with themselves. Nothing would be broken. And they would potentially be able to ask for it to be deployed into production.

  7. The product owner (and stakeholders) are able to explain every story.

  8. Members of the implementation team (not the product owner/stakeholders), are MUCH MORE focused on meeting end of sprint deliverables, rather than a future product launch deliverable.

  9. Of the various things that your team demoed, most of they them could be deployed into production.

  10. Of the various things that were demoed, the stakeholders could pick and choose some (and not all) of the things they approve to be deployed.

  11. Our stories describe new features and functionality to be built for users, rather than describing work for the implemention team to do.

Advanced

  1. When thinking about "MVP", we're really just thinking about what would be nice to have in our first release.

  2. Our automated testing continous integration build's can work offline. And don't depend on other servers being online.

  3. Stakeholders are able to demo and test new features (demoed during sprint review) before they are approved by the stakeholders and merged into the latest code base.