DEV Community

Discussion on: Sprint Demo/Retrospective Best Practices

Collapse
andy profile image
Andy Zhao (he/him)

Great advice, James. Our team has been trying different retrospective strategies, but they still feel a bit wishy washy. I think we're suffering from a lack of data and having concrete action steps to conclude the meeting.

What are your thoughts @jess and @ben ?

Collapse
ben profile image
Ben Halpern

I think it makes sense. I think we're still a bit new and small to take on some of these practices, which I think rely on a bit more consistency on inputs than we can accomplish at this time. Any given week might swing between like 170 "developer hours" and, say, 50 depending on who's doing what and keeping track of that strikes me as a bit too much overhead right now.

That being said, I think we should try to be ahead of this. Continue to refine as we grow so that at each stage we have the right amount of monitoring.

What do you think @jlhcoder , we're a pretty tiny team and wear many hats. We have demos and retros (though demos are less strictly baked into the process) but right now they are more qualitative than quantitative.

Collapse
mkuegi profile image
Markus Zancolò

Tiny team, many hats. Sounds like the more reasons for demos and retro.
In my experience, having lots of hats increases the risk of talking to less about it. But talking about it/showing it is also a good way to rethink it yourself.
I myself found lots of problems (code and concept) by showing it to someone who would have only said "looks nice", but while telling them what I did there were the famous "wait a minute"-moments ;)

Nevertheless I wouldn't go for to much metric in a small team. As you said: lots of overhead. But at least a "what did we want to achieve" vs "what did we achieve" is always possible and reasonable I think.