Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
how_can_we_improve_the_quality_of_feedback_at_a_sprint_review [2016/07/03 13:38] 127.0.0.1 external edit |
how_can_we_improve_the_quality_of_feedback_at_a_sprint_review [2018/10/04 10:55] (current) Hans Samios |
||
|---|---|---|---|
| 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, then they need to know that you are listening. This does not mean that you have to do everything that they say. The point of the collaborative nature of the feedback is that you discuss, not just agree. A valid response might be "we heard about this, think its a good idea, but think that we need to do these other things first - does that make sense to you?" | * 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, then they need to know that you are listening. This does not mean that you have to do everything that they say. The point of the collaborative nature of the feedback is that you discuss, not just agree. A valid response might be "we heard about this, think its a good idea, but think that we need to do these other things first - does that make sense to you?" | ||
| * 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 (maybe list the individual stories that correspond to each theme). | + | * Don’t go through every single user story describing it. Talk about the major goals or themes for the sprint (maybe list the individual stories that correspond to each theme). |
| - | * Don’t dwell on raw statistics like “velocity” overly much. Instead, mention whether this sprint was “better”, “worse” or “about the same” compared to historical velocity trend. | + | * Don’t dwell on raw statistics like “velocity” overly much. Instead, mention whether this sprint was “better”, “worse” or “about the same” compared to historical velocity trend. |
| - | * 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 impact the features will have on administrators, implementer in the field, and other features under consideration | + | * Discussion of impact the features will have on administrators, implementer in the field, and other features under consideration |
| - | * 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, don’t just provide the answer to them. Shut up! And stay quiet longer than you feel comfortable staying quiet. It is surprising how often people will speak to fill a void, and also surprising what you will learn as a result. | * Use silence to create pressure. If you ask a question of your stakeholders, don’t just provide the answer to them. Shut up! And stay quiet longer than you feel comfortable staying quiet. It is surprising how often people will speak to fill a void, and also surprising what you will learn as a result. | ||
| * 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>Consultant Tools SprintReview Review Feedback FAQ}} | ||
| - | {{tag>Consultant Tools SprintReview Review Feedback FAQ}} | ||
| - | |||
| - | ~~LINKBACK~~ | ||
| - | ~~DISCUSSION~~ | ||