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 revisionNext revisionBoth sides next revision | ||
how_can_we_improve_the_quality_of_feedback_at_a_sprint_review [2016/05/27 07:47] – Added note about seeing progress hpsamios | how_can_we_improve_the_quality_of_feedback_at_a_sprint_review [2020/06/02 14:22] – external edit 127.0.0.1 | ||
---|---|---|---|
Line 17: | Line 17: | ||
* 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 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, | ||
* In terms of the agenda: | * In terms of the agenda: | ||
- | | + | |
- | * 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 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 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 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. | ||
Line 43: | Line 43: | ||
* 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. | * 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. | * 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> | ||
- | |||
- | ~~LINKBACK~~ | ||
- | ~~DISCUSSION~~ |
/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