microsoft / vsts-extension-retrospectives

An Azure DevOps extension for efficient retrospectives
MIT License
183 stars 83 forks source link

Close a retrospective #45

Open sergioagm opened 4 years ago

sergioagm commented 4 years ago

Adding to this timer issue, we would like to mark a restrospective as closed.

After plenty of time has been given to the team, we could go back to the restrospective and mark is as "Done" or "Closed" to prevent further changes from being added to the cards, groups, votes and actions.

Together with a timer per "stage", we could give the Team members a timeframe to jump into the retrospective and maybe just get together for a "live" Act stage. This would allow teams distributed in different timezones to work asynchronously on providing feedback and casting their votes.

ArieHein commented 4 years ago

seen it in other requests and it keeps bugging me the over-managemental approach and lack of trust as if were not talking about people. Why would you need to consider this Done or Closed. Why do you need some much governance, where in Agile and Scrum have you read that a retrospective has a state ? instead of focusing on the content of the ideas on communicating ideas and inclusion. Who goes and changes a retrospective after votes were made and appropriate new backlog items were created ? and if you have people going in and changing stuff AFTER, I would say you have another issue all together...but mainly you have a problem with trust and communication if you have to govern this. /rant off.

sergioagm commented 4 years ago

@ArieHein I agree with your comments, and indeed this goes deeper than just marking a retrospective as Closed. Sadly, in my workplace environment, I'm in no position of power to be able to make such changes and having a simple way for someone to come and close a restrospective would help a lot.

We are undergoing a LOT of changes and its difficult to communicate effectively with my team. I'm not the scrum master nor I am the team leader, but I'm trying to do the best with the team we have to make retrospectives part of our development cycle and until everyone is on board and gets the point of them, this proposed feature would make that transition easier.

If there are any resources that I'm not aware of to help incorporate proper agile best practices then I'll be happy to hear them!

ArieHein commented 4 years ago

Keep using postit notes and once the retrospective is over, have your scrum master hide all the postit notes in a safe and melt the key, thats roughly what youre asking. I understand team diversity and management differences and when making a transformation there are a LOT of changes and people have different levels of adaptation but if you dont infuse the team with trust as a core value from the start, eventually you will fail at the process at the human level. There's even a extension in the marketplace that allows you to print the cards from the kanban in a printer and then take the results cut it to small squares and hang it on a real board just people have different handwriting styles that make it difficult later for the SM or PM to covert it to real user stories / features in the backlog. You will never hear from a scrum master of even having the ability to "close" a retrospective. Because the last stage in a retro is converting those ideas the team voted the most as work items in the backlog. From the practical level of having a state means there's someone with the ability to manage the state and since all project members are contributors a.k.a they can do everything in the project. I really really doubt you will be able to create a specific role for that unless extending the underlying RBAC of the service and im not sure that will be possible, but as its still MS, they might surprise us on that term. Still i think overall its not the best way to control work process.

oliveratgithub commented 3 years ago

Yes, please allow Retrospective Owner/Creator to close a Retrospective

Mezun commented 3 years ago

I agree with some of your points, but not all. The hyperbole is quite wrong. Its not like locking it in a safe, more like framing the results in a glass picture frame.

For example for a projekt with multiple Scrum teams i dont want other teams to interfere with my team retrospective. I dont mean deliberately, but by accident. I also dont want that some team member deletes actions from the retro because his/her cat walks oder the keyboard.

So maybe the more important feature would be that other teams cant write in another teams retrospective. This is only ment to give my team the freedom to talk about any topic they want to.