You may consider a Sprint successful if all the tasks are developed and the build doesn’t break. Or you may consider it a success if all the acceptance tests passed. Or you may consider it a success if the customer is really excited and can’t wait until the next Sprint. These are all indicators of good success. But I want to add still another success criterion. On top of all these measurements, I consider the Sprint a success if all supporting players consistently used their strengths to get the job done.
Being a maximizer, I am consistently looking for ways to improve the software development lifecycle and one of the best ways to improve the lifecycle is to improve the experience of the people who are responsible for bringing the cycle to life. But how do you measure “improved experience”?
At the beginning of each Sprint make three statements about how you propose to use your strengths to achieve Sprint and corporate goals. For example 1) I will use my analytical strength to Optimize System Quality by taking ownership of the test tasks; 2) I will use my command strength to Optimize Application Architecture by confronting those who do not follow the selected architectural patterns; 3) I will use my input strength to Optimize Implementation by noting the various styles being used in the application code.
At the end of the Sprint, during the Sprint Retrospective, rate your success according to the following criteria (or improvise) and use the ratings to develop your skills & expertise so that each successive Sprint will bring you even greater fulfillment.
I met my Goal!
- strongly agree
- strongly disagree
Reasons for ratings of 3, 4, and 5
- lack of skill (e.g. tried but didn’t do as well as expected)
- lack of opportunity (e.g. no tasks available)
- lack of time (e.g. other tasks took priority or PTO)