Most organisations using an Agile methodology think they’re agile.
But it’s actually difficult to objectively measure how well your team is conforming to Agile principles.
Could your team be doing even better?
Let’s say that since implementing Scrum or another Agile approach, project performance and overall revenue have both significantly improved. Project delivery times have been reduced by 10% and revenue is up 15%. That’s great progress. But are you being complacent and neglecting some of the core Agile principles just for a ‘tick’ that against Agile being implemented? Could these improvements be doubled?
This is where conducting an Agility test can be beneficial. It provides a way of measuring not just how Agile you think your company really is, but also how your team’s performance is perceived by your most important assets – the team members themselves.
The 50 Point Test
The following is a set of 50 questions that you can ask yourself and your team to help determine just how Agile you really are. Each question can be answered by a Yes/No answer, allowing you to arrive at a score out of 50 for each respondent.
Ask every team member of each Agile team, including the Product Owner, testers, and managers to honestly answer each statement. The responses must be consistent with their belief that it is actually happening i.e. it should be audit-able. If the respondent is unsure whether they could provide evidence that it is happening then they should respond “No” for that statement.
Take the interactive 50 Point test here.
- The team knows who the Product Owner is.
- The role of the Product Owner is clearly defined.
- The Product Owner is actively involved throughout each sprint.
- The Scrum Master helps to resolve issues that are not in the hands of the team.
- Each sprint/iteration has a clear goal.
- The team uses a whiteboard to display the goal of each sprint/iteration.
- The team whiteboard is used to show clear visibility of progress and issues on a daily basis.
- All User Stories and tasks are displayed on the whiteboard for the duration of the sprint/iteration.
- Potential issues that may hold up progress are raised in the daily scrum, recorded on the team whiteboard and resolved in a timely fashion.
- Sprints/iterations are time-boxed to four weeks or less.
- The sprint budget is calculated to determine how many product backlog items or features can be included in the sprint/iteration.
- Software is tested and working at the end of each sprint/iteration.
- Changes are integrated throughout the sprint/iteration.
- All tasks on the sprint backlog are broken down to a size that is less than one day.
- Stretch tasks are identified for inclusion in the sprint/iteration if it is progressing better than expected.
- The team is not disrupted during the sprint/iteration.
- The sprint/iteration ends on the agreed end date.
- Overtime is not usual practice.
- Daily scrums happen at the same time every day, even if the ScrumMaster is unable to be present.
- The daily scrum is restricted to answering the standard three scrum questions and does not last longer than 15 minutes.
- The team knows what their velocity is.
- Velocity is used to gauge how many User Stories should be included in each sprint/iteration.
- User Stories are listed and prioritised before sprint planning.
- The team is self-organising and doesn’t rely on management to set or meet its goals.
- The team is empowered to make decisions.
- The team takes responsibility for delivery and is willing to help with any task that helps the team achieve its goal.
- All team members, including testers, are included in requirements workshops.
- Test cases are written up-front with the requirements/User Story.
- There is a product backlog/feature list prioritised by business value.
- The product backlog estimates are created by the team.
- The team estimates using points that indicate the relative size of each feature on the product backlog/feature list.
- The team generates burndown charts to track progress daily.
- Requirements are expressed as User Stories and written on a card.
- Unit testing is implemented where appropriate.
- An automated build and regression test is used.
- The test cases are clearly defined.
- Defects are fixed within the same or next iteration.
- All code changes are reversible and it is possible to make a release at any time.
- Continuous refactoring is part of the team’s coding habits.
- Testing is integrated throughout the lifecycle and starts on delivery of the first feature.
- There is a product demonstration/sprint review meeting held at the end of each sprint/iteration.
- All team members, including the Product Owner and testers are included in the sprint/iteration review.
- The sprint/iteration review is also attended by executive stakeholders.
- There is a sprint retrospective at the end of each sprint/iteration.
- Key metrics are reviewed and captured during each sprint retrospective.
- All team members, including testers, are included in the sprint retrospective meeting.
- Honest, open-minded, and creative discussions and critiques are made during the retrospective.
- Actions from the sprint retrospective are implemented to benefit the next sprint/iteration.
- The team and stakeholders are satisfied with the quality of the product.
Once each team member has completed the 50 point test, add up the points for each respondent and average them to arrive at a total score for the team. Ideally you should be looking to get an average score in excess of 40 points.
If your team’s score is below 40, you should be looking to update your processes and team culture. Even if you score above 40, you should be looking to improve this score over time so it’s worthwhile revisiting this 50 point test again in the future.
Are you considering implementing an Agile solution in your organisation? Finite IT can help you find the right people from your team. From Product Owners, testers, managers and the development team. Get in contact today.