how_do_we_talk_about_sprint_commitments_that_have_not_been_met_in_the_sprint
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | Next revisionBoth sides next revision | ||
how_do_we_talk_about_sprint_commitments_that_have_not_been_met_in_the_sprint [2016/07/03 13:38] – external edit 127.0.0.1 | how_do_we_talk_about_sprint_commitments_that_have_not_been_met_in_the_sprint [2016/10/07 07:16] – hpsamios | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== How Do We Talk About Sprint Commitments That Have Not Been Met / Done? ====== | ====== How Do We Talk About Sprint Commitments That Have Not Been Met / Done? ====== | ||
- | At the beginning of the sprint | + | At the beginning of the Sprint |
But the reality is that the commitment is not a guarantee. The team will discover things and things will happen even in as short a period as a sprint. For example, there could be an outside impact on the team (more production support than expected); the job could have been harder than expected (“oh my, look at this code - wtf?”); as the work was being done, it became clear that the requirements needed to change or be different; and so on. In these cases, from the stakeholder' | But the reality is that the commitment is not a guarantee. The team will discover things and things will happen even in as short a period as a sprint. For example, there could be an outside impact on the team (more production support than expected); the job could have been harder than expected (“oh my, look at this code - wtf?”); as the work was being done, it became clear that the requirements needed to change or be different; and so on. In these cases, from the stakeholder' | ||
- | During the Sprint Review when the team is talking about the Sprint (eg by presenting the Sprint Burn-down chart as a backdrop), the Team should provide explicit data on the “not done” items so they can be seen to be accountable to the commitments they made. This can be as simple as listing out the items that were not completed. | + | During the Sprint Review |
- | Here is the key thing. We then talk about why the team was unable to meet the commitment and, if it makes sense, talk about possible learning we have made that we expect will allow us to deal with similar situations in the future. Keep the discussion short and focused on improving how we deliver business value. | + | Here is the key idea. We are focused on the delivery of value and we want to be unambiguous about what the status is of the work we have done. Working software is the primary measure of progress. The assumption is that we worked hard to progress and complete the work and we prove that by showing Sprint Burn-down and other artifacts. We do not talk about how much effort we put into the work as that just sounds like we are making excuses. Worse it muddies the waters in the minds of our stakeholders as to whether something is really done or not. We talk about why the team was unable to meet the commitment and, if it makes sense, talk about possible learning we have made that we expect will allow us to deal with similar situations in the future. Keep the discussion short and focused on improving how we deliver business value. |
- | This is not a blame game where we are looking for the scapegoat. But it is also in sharp contrast to what is often heard at these status meetings. For example, we often hear “I think we did a great job … if you just look at the results from this perspective.” We hear long winded excuses couched in techno-babble on why we weren' | + | This is not a blame game where we are looking for the scapegoat. But it is also in sharp contrast to what is often heard at traditional |
- | No matter the motives, this approach does not increase a stakeholder’s ability to trust the team the next time around. The stakeholder has it in the back of her mind “what's to stop this from happening again?” The best response is to be upfront about the miss and clear about what you have learned as a result. | + | I think we hope that people won't really see what this means, that we did not make the commitment, and hope that people forget that they were after specific business value. |
+ | |||
+ | No matter the motives, this approach does not increase a stakeholder’s ability to trust the team the next time around. The stakeholder has it in the back of her mind "what's to stop this from happening again?" | ||
{{tag> | {{tag> |
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/how_do_we_talk_about_sprint_commitments_that_have_not_been_met_in_the_sprint.txt · Last modified: 2022/08/09 08:30 by hans