Software development in most startup teams today has essentially become ticket-driven development. Tickets are created, assigned, and are magically expected to be delivered on in 1 or 2-wk cycles. Then, more new tickets are created, assigned, and the cycle repeats.<p>The PM/EM writes a bunch of poorly detailed tickets (often with no detail) and expects devs to deliver on them. Is this the situation in your team too? If there is detail, it's usually a few hastily written lines in the JIRA ticket description with the rest left to the developer to figure out, fill in the blanks on, or ask questions around.<p>1. have you experienced this? and if so, have you seen that this leads to poorer quality deliverables or does it not have any impact?<p>2. what would you fix about this process (systems, people, tools) to make it better?
Where I am today I often get tickets that are too vague to start on.<p>I think about it a bit, spend ten minutes talking to the person who wrote the ticket, turn the ticket into a good ticket, and proceed.<p>The effort to do that is maybe 5% of the work to complete the ticket so I can't complain.<p>Even though we do sprints what we are doing is really kanban where the main focus is finishing what we start and not having excess WIP. If a ticket takes a sprint and a half to finish, there is always something from the backlog to add to the sprint.<p>There are many ways to use a ticket system. One of the times I was happiest was when I was able to quickly break down my work into 10-20 minute subtasks and make super-accurate estimates. That was dependent on having a framework in which the tasks were predictable and also quickly punching tasks into a spreadsheet. If the work involved a lot of struggling with the runtime, build system, algorithms, database, etc. that kind of predictability is impossible.<p>There is always some disconnect between "what we say we do" and "what we really do" in a ticket system. Those agreements and disagreements can drive people crazy (fine-grained tasks help me focus but will drive many people up the wall) but it's also possible to reach an accommodation where work gets done without a lot of space.<p>(e.g. it drove me nuts to write a daily standup summary of yesterday and today in the morning with the rest of my team. in the morning I'd find it hard to remember exactly what i did yesterday and what I was planning to do last afternoon and it would slow me down getting to work. Now I write my summary when I leave with the headlines "what i did" and "what i plan to do" that recognizes that those things don't always agree. Those notes help me get started in the morning and nobody complains I am 180° out of phase.)
Establish 1 year product road map. Break down that year into quarters and so on.<p>Hire someone to help you offload tasks so you can focus on long term growth or to help you with the long term vision.<p>If resources are limited, at least take a week or 2 to plan this road map.<p>(I am in a similar situation)
Yes. Estimation has about a 50/50 chance of being correct. When it's wrong management is unhappy and thinks we're doing it wrong.<p>Change? Use the cards as a guide only.