how_can_we_improve_the_quality_of_feedback_at_an_iteration_demo
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
how_can_we_improve_the_quality_of_feedback_at_a_sprint_review [2018/10/04 10:55] – hpsamios | how_can_we_improve_the_quality_of_feedback_at_a_sprint_review [2021/05/04 11:20] – Added want to know more. Cleaned up. Added applicable to System Demo hans | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== How Can We Improve The Quality of Feedback at a Sprint Review? ====== | + | ====== How Can We Improve The Quality of Feedback at a Iteration Demo (Sprint Review)? ====== |
- | I’ve had a number of discussions with teams recently where people are questioning | + | Or "How do we improve |
- | Some of this is, of course, | + | I’ve had a number of discussions with teams recently where people |
- | | + | Some of this is, of course, a self-fulfilling prophecy. If you are not excited about the work you have completed and the Iteration Demo (Sprint Review) you are about to undertake, how can you expect your stakeholders to be excited. It turns out that many teams are, in fact, in a rut. Symptoms include: |
+ | |||
+ | | ||
* Management is invited, but increasingly do not show up. In the past there was excitement to see progress via a demonstration but today that is considered normal and reporting of progress is so open and transparent that management don’t feel the same need that they did in the past to participate. | * Management is invited, but increasingly do not show up. In the past there was excitement to see progress via a demonstration but today that is considered normal and reporting of progress is so open and transparent that management don’t feel the same need that they did in the past to participate. | ||
* When management do show up the only thing that is heard is “good job.” Some management are not sure what else they should be saying to a self-organized team. Sometimes management is there in body but not in mind (eg engaged in email on their cell) leaving a poor impression about the importance of the work or their willingness to work issues. | * When management do show up the only thing that is heard is “good job.” Some management are not sure what else they should be saying to a self-organized team. Sometimes management is there in body but not in mind (eg engaged in email on their cell) leaving a poor impression about the importance of the work or their willingness to work issues. | ||
Line 11: | Line 13: | ||
But much worse than this, we are also not getting any feedback from customers. | But much worse than this, we are also not getting any feedback from customers. | ||
- | The purpose of the Sprint Review is to get feedback on the increment just delivered by the team. Like all feedback the idea is to do this so that feedback is easily given (“frictionless”), | + | The purpose of the Iteration Demo (Sprint Review) is to get feedback on the increment just delivered by the Team. Like all feedback the idea is to do this so that feedback is easily given (“frictionless”), |
Some things that will help: | Some things that will help: | ||
- | * During the next Sprint Review make sure you are clear about what happened to the feedback in the previous Sprint Review. If you want your stakeholders to participate, | + | * During the next Iteration Demo (Sprint Review) make sure you are clear about what happened to the feedback in the previous |
* In terms of the agenda: | * In terms of the agenda: | ||
- | * Don’t go through every single user story describing it. Talk about the major goals or themes for the sprint | + | * Don’t go through every single user story describing it. Talk about the major goals or themes for the Iteration (Sprint) |
* Don’t dwell on raw statistics like “velocity” overly much. Instead, mention whether this sprint was “better”, | * Don’t dwell on raw statistics like “velocity” overly much. Instead, mention whether this sprint was “better”, | ||
- | * Do get as quickly as possible to the things that we really want to discuss with our stakeholders. If you take more than 5 mins to get to the demos you might want to review what is happening and make sure that what is happening helps rather than hinders the purpose of the Sprint Review. | + | * Do get as quickly as possible to the things that we really want to discuss with our stakeholders. If you take more than 5 mins to get to the demos you might want to review what is happening and make sure that what is happening helps rather than hinders the purpose of the Iteration Demo (Sprint Review). |
* Don’t ask for feedback, but rather drive the conversation. For example you could say “As we were working this item we were thinking that this other feature is required, what do you think?” or “We came up with two approaches to this and settled on this one – what directions would you have taken?” While you may not change anything as a result of saying these things, you will encourage a different level of participation which will offer up improved opportunities to learn. Other ways to drive the discussion include: | * Don’t ask for feedback, but rather drive the conversation. For example you could say “As we were working this item we were thinking that this other feature is required, what do you think?” or “We came up with two approaches to this and settled on this one – what directions would you have taken?” While you may not change anything as a result of saying these things, you will encourage a different level of participation which will offer up improved opportunities to learn. Other ways to drive the discussion include: | ||
* Discussion of impact the features will have on administrators, | * Discussion of impact the features will have on administrators, | ||
* Discussion of items that affect development work in other teams | * Discussion of items that affect development work in other teams | ||
* Use silence to create pressure. If you ask a question of your stakeholders, | * Use silence to create pressure. If you ask a question of your stakeholders, | ||
- | * Split the job of facilitation (Scrum Master) from collecting and discussing feedback (Product Owner). Some Scrum teams report that the Product Owner behaves more like a stakeholder than a team member. The Product Owner should drive feedback conversation since it is a conversion that directly impacts the Product Backlog. Also customer relationships are often through the Product Owner and so a lack of participation by the Product Owner creates a strange dynamic. | + | * Split the job of facilitation (Scrum Master) from collecting and discussing feedback (Product Owner). Some Agile teams report that the Product Owner behaves more like a stakeholder than a Team member. The Product Owner should drive feedback conversation since it is a conversion that directly impacts the Product Backlog. Also customer relationships are often through the Product Owner and so a lack of participation by the Product Owner creates a strange dynamic. |
- | * Make sure the Product Owner does a summary of what was discussed and potential impact on the product backlog. This makes stakeholders feel that input / involvement in sprint review | + | * Make sure the Product Owner does a summary of what was discussed and potential impact on the product backlog. This makes stakeholders feel that input / involvement in Iteration Demo (Sprint Review) |
- | * Place sprint review | + | * Place Iteration Demo (Sprint Review) |
- | * Don’t be afraid to rotate (especially customers) stakeholders off the Sprint Review and bring in a fresh viewpoint (and excitement). I understand this has political overtones, so be careful how you do this. | + | * Don’t be afraid to rotate (especially customers) stakeholders off the Iteration Demo (Sprint Review) and bring in a fresh viewpoint (and excitement). I understand this has political overtones, so be careful how you do this. |
- | * Some teams indicate that they are getting feedback but it is not related to the subject at hand (eg bug reports, demanding new features). If there are issues not related to feedback that arise in the review, the Scrum Master should facilitate – “I will set up meeting to discuss …” | + | * Some Teams indicate that they are getting feedback but it is not related to the subject at hand (e.g. bug reports, demanding new features). If there are issues not related to feedback that arise in the Iteration Demo (Sprint Review), the Scrum Master should facilitate – “I will set up meeting to discuss …” |
- | * Occasionally ask your stakeholders for ideas on how to improve the Sprint Review. In others words do a Retrospective of the Sprint Review. This could be done at the end of the Sprint Review or as a separate activity (eg survey). Start the conversation with “We want to make sure that the Sprint Review offers a good return for the amount of time you have invested with us … what would you like to see us change about the Sprint Review to make them more useful to you?” | + | * Occasionally ask your stakeholders for ideas on how to improve the Iteration Demo (Sprint Review). In others words do a Retrospective of the Iteration Demo (Sprint Review). This could be done at the end of the Iteration Demo (Sprint Review) or as a separate activity (e.g. survey). Start the conversation with “We want to make sure that the Iteration Demo (Sprint Review) offers a good return for the amount of time you have invested with us … what would you like to see us change about the Iteration Demo (Sprint Review) to make them more useful to you?” |
- | In most cases, the most important feedback is provided by customers of the product. Feedback from internal stakeholders can be around the functionality but more importantly is about making sure the team is addressing the technical and directional things they should be and, if they aren’t, determining how they can be helped to do the right thing. Internal stakeholders also help increase | + | In most cases, the most important feedback is provided by customers of the Product. Feedback from internal stakeholders can be around the functionality but more importantly is about making sure the Team is addressing the technical and directional things they should be and, if they aren’t, determining how they can be helped to do the right thing. Internal stakeholders also help increase |
* “How do you feel about the quality of the work you have done?” | * “How do you feel about the quality of the work you have done?” | ||
Line 37: | Line 39: | ||
* “How do you know?” | * “How do you know?” | ||
- | If you have nothing to input at least be explicit about what you think was good (eg “After seeing the demo, I cannot come up with anything I would have changed or done differently. BTW I really liked the way the user interface came together here.”) | + | If you have nothing to input at least be explicit about what you think was good (e.g. “After seeing the demo, I cannot come up with anything I would have changed or done differently. BTW I really liked the way the user interface came together here.”) |
+ | |||
+ | The general principle of Product feedback is to do whatever it takes to allow feedback on your Product with minimal friction, within the shortest time-frame possible and so that the feedback is received in context. The Sprint Review is just one opportunity to get this. Other ways to get increased Product feedback include: | ||
+ | |||
+ | * Not everyone can be involved in every Iteration Demo (Sprint Review) and there maybe situations where a you need another “review” session. For example, field / customer leadership might not be able to be involved in each and every Iteration Demo (Sprint Review) but we would like their input. One idea is to set up a special event for this. We are seeing, for example, PSI (Potentially Shippable Increment) Review or System Demo where demos are pulled together that combine the work of multiple Teams over multiple Iterations (Sprints). The downside is that this feedback loop is longer than if they were providing feedback at the Iteration Demo (Sprint Review) and the people involved need to understand that our ability to change course will be slower. At least the feedback comes in before the product is released. | ||
+ | * One that we probably don’t use enough of is feedback directly from a user on one of our screens to the product owner. For example Atlassian puts a “Feedback” button on all screens in their product which then send information back to the Product Owner. The context defined by screen user is on and in the background the tool gathers up information on configuration. The form is very simple (summary, description and optional attachments) so there is no friction to the user to provide the information. In particular, the form does not ask any “who” information – it is more important to get the feedback than to understand the specific person it came from. Again the product feedback cycle is longer than what we’d do with a Sprint Review but it still helps inform decisions about the product. | ||
+ | |||
+ | Note: that most of this thinking applies to higher level demonstrations, | ||
+ | |||
+ | ====== Want to Know More? ====== | ||
- | The general principle of product feedback | + | * [[how_do_we_run_our_first_iteration_demo_or_sprint_review|How Do We Run Our First Iteration Demo (Sprint Review)? |
+ | * [[what_is_the_purpose_of_iteration_or_sprint_goals|What | ||
- | * Not everyone can be involved in every Sprint Review and there maybe situations where a you need another “review” session. For example, field / customer leadership might not be able to be involved in each and every sprint review but we would like their input. One idea is to set up a special event for this. We are seeing, for example, PSI (Potentially Shippable Increment) Review where demos are pulled together that combine the work of multiple teams over multiple sprints. The downside is that this feedback loop is longer than if they were providing feedback at the Sprint Review and the people involved need to understand that our ability to change course will be slower. At least the feedback comes in before the product is released. | ||
- | * One that we probably don’t use enough of is feedback directly from a user on one of our screens to the product owner. For example Atlassian puts a “Feedback” button on all screens in their product which then send information back to the product owner. The context defined by screen user is on and in the background the tool gathers up information on configuration. The form is very simple (summary, description and optional attachments) so there is no friction to the user to provide the information. In particular, the form does not ask any “who” information – it is more important to get the feedback than to understand the specific person it came from. Again the product feedback cycle is longer than what we’d do with a Sprint Review but it still helps inform decisions about the product. | ||
{{tag> | {{tag> | ||
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/how_can_we_improve_the_quality_of_feedback_at_an_iteration_demo.txt · Last modified: 2021/05/04 11:21 by hans