Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Disadvantages:
Team will not feel free to talk about issues.
Advantages:
Project management and management like to know what is going on.
How should this be done? Getting conflicting reports here…
Sprint retrospective and Sprint review are two different things that shouldn’t be confused.
Sprint review is for everyone involved, especially stakeholders, to inspect where the project is and discuss how to adapt as needed. Sprint review revolves around the “shippable product increment” produced in the last sprint – not how it was produced.
It is good if Product Owner “represents” stakeholders, but it is even better if they can see themselves what was accomplished, what runs etc. So I’d say welcome management of all kinds if they want to come to sprint review, but be careful to at least tell them what that meeting is and what their role is. I’d say that educating them is primarily PO’s job, SM may assist him.
Sprint retrospective is primarily for the team to inspect their last sprint, concentrating less on what was done than on how it was done. I wouldn’t include anyone besides PO if he/she wants to join in those. Your objection that team may not be comfortable talking about their dirty laundry in front of management is very valid – but also from managements’ prospective this would be waste of time to, for example, listen to developers debating how to improve branching in their code repository. Even if the management knew what the heck team is talking about this is not something they should waste their time on – they have bigger picture to manage.
Having said that an overall retrospective on the project or on a longer chunk of it (like a quarter or half year) that would include management may make sense, but it would not necessarily include all team members (if you have many teams that would make it impossible) and would concentrate on “big picture”.
Speaking of books – definitely buy “Agile Retrospectives”. There is not much to read there – it is just a great cookbook of various techniques to use in different phases of a retrospective based on how much time you have and what is the retrospective about. Great help, since classic “what we did well? what we didn’t do wellt?” etc. becomes boring pretty quickly.