As a product owner, I need the commitment between the product owner and the release manager to be documented prior to the sprint beginning.
In my previous post I described the genesis of the sprint contract idea based on a blog post I read. I also described why there was a need for such a document. This post will go over some of the mechanics of how my release manager would create such a document.
In order for this exercise to be useful, there are a few key parameters that must be considered.
In order for the contract to have any real impact on the outcome of the sprint it must be produced in advance of the sprint planning meeting. It will go through a couple of revision cycles as I negotiate priority user stories with the release manager.
The release manager spends a lot of time in our backlog of user stories, so the idea of creating a separate document at first seemed like an extra step. As the product owner, I felt that producing this artifact outside of the system used to manage the backlog provided some advantages to me. Probably the most important advantage was that I did not need to sift through the details myself, which allowed me to easily focus on the stories at hand and quickly give feedback to drive priorities. From the release manager’s point of view, if the stories are written well in the backlog system, it should be a matter of cut and paste to create the document, followed by some minor edits.
A key tenant of Agile is to produce just the right amount of documentation to support the software development process. An important part of the sprint contract is keeping it to one page in length. One page helps keep the content at the right level of detail, plus it makes for an easy-to-use scorecard I like to use at the sprint review to evaluate whether or not each of the commitments were met.
Stretch the Team
At the beginning of implementing this process, I was most concerned that the document would either have a far too aggressive scope. If they were unable to complete every commitment on the document, they would feel as though they had failed. As the product owner, the challenge during the editing process would be to get as much as possible in the scope of the sprint. I found the key was to go for a stretch of the scope to maybe a story or two beyond what I thought could be accomplished. In future posts, I will present some data to give an idea of how much to expand the scope. My goal was to never achieve 100% as then I knew that more could likely have been finished in the sprint.
Working Software Is The Priority
The stories in the sprint contract must represent working software to be demonstrated in the sprint review. Any stories that don’t should not be on the sprint contract document. Again, this document sets the stage for the sprint review, so other user stories (for example, we like to have process improvement stories) are not necessarily interesting for the attendees of the sprint review to discuss.
I like to use this document as a scorecard, so the items listed on the document should be written in a way that makes it easy to assess success for each item on the document. This is important to the team so they know what the definition of success will be as the product owner follows the events of the sprint review.
In the next post, I will talk about the impact the Sprint Contract has made with my team, including the data. Hope this is useful, as it has really helped.