3 ms·

I suspect that you did not managed expectations. PO was not really working as the proper owner and have no clue about progress and effort being put. Your direct

I suspect that you did not managed expectations. PO was not really working as the proper owner and have no clue about progress and effort being put. Your direct manager does not care as it can always blame everything on you. And the team is not so great if they have problems with "comfort zone". First get PO on board. Choose the process that will push PO into the central role: Kanban, Scrum, XP(anything really). Work with the PO to create user stories, estimate and calibrate. PO should work with stakeholders to ensure that the timeline is realistic. Get your team a proper training. Hire someone to do training on the tech you use. Get some courses from Pluralsight/Udemy that will be mandatory for everyone on the team. Extra day in month spend on training is not much but it will up-skill people quickly. Drag in your manager. Get him into a meeting and ask for a guidance of the senior manager. Make him co-responsible, he might help with funding on the project. Cut features to absolute MVP. If nothing works, escape sinking ship.

kimdotcom 8y ago
This is the best advice here. I would work for you.
adrianhel 8y ago
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!"

kimdotcom 8y ago

This is the best advice here. I would work for you.

adrianhel 8y ago

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!"