3 ms·

All this really means is either - You can only ever work on projects which are finished in one sprint. - You have no idea how, when, or even why the big initi

• user_named 4y ago
  Your first point is exactly true. We design concepts with certain goals in mind, then that gets cut down into something that takes one or two sprints of work "to see the results", which never come because it does not even cover mvp use cases. Then the rest never gets built. Absolutely lack in long-term thinking, goals and vision.
• kube-system 4y ago
  If you have a large project, you break it down into smaller parts. If you know what needs to be done, throw it in the backlog, give it a broad estimate, sort it, and you have an estimate for about how long it will take. If you have unknowns, make resolving them a task. If you need things from the business, give them tasks. > It's not practical to build a business this way, what happens when one team pulls priority and a different one next week? Someone has to own the project, and have the final say on priority. If the project is at risk due to shifting priorities, you need to escalate this to them for a final decision. > You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy. If you have everything in your backlog, you can judge velocity to come up with an estimated timeline given all of the assumption at the current state. This isn’t a promise, it’s an estimate. When the business shows up to sprint planning and sprinkles around new ideas for high priority tasks, you always remind them that this means deprioritizing other tasks which will affect timeline. > what happens when a multi-sprint project becomes a multi-year forever project? Yes, at the end of the project you will likely have done something very different than what you originally put in your backlog, because the business will have changed their minds 100 times. This is the point! The point is to track close to building what they want, not to build what they wanted 8 months ago.
  • OnlyMortal 4y ago
    Nice summary and also my view. I like to say that the whole point in the estimates is to set expectations. At that point a discussion is had with the stake holders. If you know the velocity of the team, because it’s actually been measured (a rare thing in my experience), you will have a good idea on what is actually possible within a time frame.
  • lumost 4y ago
    > you have a large project, you break it down into smaller parts. If you know what needs to be done, throw it in the backlog, give it a broad estimate, sort it, and you have an estimate for about how long it will take. If you have unknowns, make resolving them a task. If you need things from the business, give them tasks. What’s the difference between this and “waterfall” then?
    • kube-system 4y ago
      It’s a vague todo list instead of a project plan. There are no dates or resources assigned to tasks. And you’re not committed to doing any of it yet. You might change items, add items, or remove items.
    • CRConrad 4y ago
      > What’s the difference between this and “waterfall” then? The difference between this and “traditional waterfall” is that you do this continuously, simultaneously with implementation, and not just once, up-front before building anything. (At least that's the common picture of “waterfall” -- which of course proponents of various “agile” methodologies prefer to contrast their product against -- though IIRC Brooks or someone had proposed / recorded iteration on this in parallel with implementation long before the Agile Manifesto.)