As part of our commitment in Agile to constantly improve, we hold a ‘team retrospective’ every week where we look at our process and find out what we are doing well, what we can improve on and some kind of action we can take in the next week to accomplish this.

In the Scrum methodology, every sprint, we hold a planning meeting where we commit to a certain amount of work that should be completed. In return for that commitment the Product Owner ‘freezes’ the iteration - meaning that no significant change can be introduced until the next planning meeting. So all the software teams at Integrum came up with the following to try to pin down what commitment and frozen iterations mean to us, and what we can do to be sure that our commitments are attainable.

As a retrospective facilitator, I try to keep my own opinions on a leash so that the team is able to make discoveries for itself. So this does not necessarily represent the views of this particular Scrum Master. Peace.

This friday, April 17th, the integrum team established these priorities in order to be able to give working commitments according to the Scrum methodology:

• Review the iteration with the client before planning meeting
• Provide highly visible documentation of process
• Communicate challenges in meeting our commitment early
• Stick to our guns on commitments and frozen iterations
• Set expectations for next iteration early
• Remember to keep it simple, stupid

We reviewed sprint planning in the scrum paradigm and emphasized commitment and frozen iterations. We then broke up into 3 teams to gather data. Each team reported back (in terms of commitment) benefits, difficulties, Product Owner and Development team requirements.

Benefits

1. We know what we need to do for the week
2. We set the Product Owner’s expectations
3. We can more easily hold each other accountable
4. We can track the progress of the week through metrics
5. We only start work we think we can finish
6. We only have to discuss work that will be completed for the week
7. We can focus better with less interuptions
8. We can achieve done is done
9. We get a fixed iteration
10. We get visibility on the goal

Difficulties

1. We don’t always have accurate estimates
2. We find it hard to correct the Product Owner
3. Product Owners aren’t well educated on the process
4. Product Owners change their needs during the week
5. We find it easier to commit than the Product Owner
6. We don’t like it when we don’t deliver on the commitment
7. We find it difficult to get all details in one meeting
8. Product Owner’s don’t always know what they want
9. We might have to work overtime to meet our commitment

Requirements for the Product Owner

1. Product Owner needs to provide acceptance criteria for all work
2. Product Owner needs to provide comps for visual design
3. Product Owner should have prioritized backlog
4. Product Owner should have education on frozen iterations
5. Product Owner should have requirements ready before planning meeting
6. Product Owner can’t change requirements in the middle of the week
7. Product Owner needs to be able to answer questions for all work
8. Product Owner needs to avoid interrupting
9. Product Owner needs to be highly available

Requirements for Development Team

1. We need to ask questions
2. We should avoid assumptions
3. We should provide our best effort
4. We should communicate challenges early
5. We should evaluate Acceptance Criteria
6. We should deploy often for feedback
7. We should keep it simple (stupid)
8. We should complete all the work we committed to
9. We should educate the client on the process (continually)
10. We should be willing to say no to the client
11. We should hold ourselves accountable to our commitment
12. We should actually make a commitment

Tags: Agile Software Development, Commitment, Retrospective, Scrum, Transparency