3 ms·

And if it's an online solution, propose to roll out some features gradually. But yeah: 1. Be honest with everyone 2. Invest in online courses for everyone 3. L

And if it's an online solution, propose to roll out some features gradually. But yeah: 1. Be honest with everyone 2. Invest in online courses for everyone 3. Lay out a simple roadmap for the minimum MVP 4. Hustle And next time use my recipe for estimating. Spend ~ a day on this. 1. Split up everything into the smallest subtasks 2. Estimate the time all subtasks take. Uncertain? Write down a low and a high. Still uncertain? Split the task into subtasks or confer with someone. 3. Add the times together and multiply by pi. If applicable, do it once for the high and once for the low. 4. Present the high estimate. It is probably closer to the truth. Estimating the low as well is more of a psychological trick. Don't use the subtasks for the development though. They will be too fine grained.

kefabean 8y ago
The multiply by three approach has also worked for me in the past. People often estimate the time taken to do the task, typically not taking in to consideration the other aspects of their job (eg comms/planning/rework/productionisation/etc) needed to get said task done. I do like the use of pi though, I’ll be adopting this going forwards!
- sbov 8y ago
  With experience you can account for this. What's hard to account for is some 3rd party vendor blowing you off, or slow rolling you, for weeks. Or management pulling you into another project. Each integration point with a 3rd party automatically adds an extra 1 week+ to my estimates, depending upon the complexity.
Spoom 8y ago
Personally I prefer story points per card, and then calculating the average velocity of the team per sprint vs. the number of story points left in the backlog. This presumes a deadline more than a sprint away, though, since it's a little fuzzier. Mostly it keeps people away from saying "Hey, we said this card would only take X hours!"

kefabean 8y ago

The multiply by three approach has also worked for me in the past. People often estimate the time taken to do the task, typically not taking in to consideration the other aspects of their job (eg comms/planning/rework/productionisation/etc) needed to get said task done. I do like the use of pi though, I’ll be adopting this going forwards!

sbov 8y ago
With experience you can account for this. What's hard to account for is some 3rd party vendor blowing you off, or slow rolling you, for weeks. Or management pulling you into another project. Each integration point with a 3rd party automatically adds an extra 1 week+ to my estimates, depending upon the complexity.

Spoom 8y ago

Personally I prefer story points per card, and then calculating the average velocity of the team per sprint vs. the number of story points left in the backlog. This presumes a deadline more than a sprint away, though, since it's a little fuzzier. Mostly it keeps people away from saying "Hey, we said this card would only take X hours!"