Before asking for any kind of size or complexity estimate, I ask “is this card ready?” and “is it as small as it can be…yet?”. If we agree that the card was ready and that it is as small as it can be, I suggest moving on to another card.
I’ve been looking for a silver bullet that will make this “resourcing” strategy somehow less terrible for trying to be agile but… there isn’t one. Whichever way you slice it, making people less than 100% on the team creates dysfunction.
It makes scheduling team collaboration opportunities difficult. It also means that people on more than one team spend more of their time with agile meetings than they should (think two or three lots of sprint reviews, planning meetings, retros…) - or they skip meetings because they have to. Perhaps most insidiously, it means that people are probably 100% ‘utilised’, at least. We know what happens to lead time as untilisation approaches 100%, right? It increases exponentially. So, basically, it’s a nightmare.
I’ve never been very confident trying new things for the first time in a retrospective meeting. I recently, and very belatedly, read Agile Retrospectives by Diana Larsen and Esther Derby and realised the importance of really covering the five stages they recommend. It gives the retro a solid structure and makes me more confident about trying new approaches within the structure.
At the moment I’m working with remote teams. We do retrospectives over HangOuts using https://realtimeboard.com/. The results are sometimes frustrating, often hilarious and always worthwhile.
Software products and services need a business goal. We also need to know who the product is for, the problems it solves for them and why it’s better than the alternative. This is the sort of value proposition statement we need to articulate so that we can make good decisions during the long and complex process of making software:
<statement of need>
THE PRODUCT IS A
<key benefit, compelling reason to buy>
<compelling statement of differentiation>