New answers tagged

0

You can't do long-time planning with Scrum either. In Scrum velocity is used to plan the next Sprint (aka yesterday's weather estimates). It's a quantity that changes with time and isn't suitable for long-time planning. Not to mention that you don't estimate stories outside of the Sprint and therefore you can't know how many Story Points the backlog contains....


1

Great question! Kanban works best when all tasks are a very similar size. Your team's velocity is simply the rate at which they complete tickets. This makes predicting effort reasonably easy. Which ticket size to use? From experience, 3-5 days works quite well. If a ticket is larger than 5 days, we split into smaller tickets. If a ticket is only 1-2 days, we ...


-2

Gotta say this, also ... "story points (SP)" cannot be relied upon to truly describe the internal complexity of any software system which has been devised to satisfy them. "Story points" are a measure of externally-visible functionality as seen from the point-of-view of a narrowly-defined set of users. The underlying software system ...


2

With Scrum you can try to plan longer releases using team velocity. If team velocity is 100 Story Points (SP)/Sprint and the Product Backlog has 1000 SP then you can say you can finish in 10 Sprints. Theoretically, yes. In the real world, though, if you can have your scope of work so well-defined, why are you using iterative and incremental methodologies? ...


2

Daniel is spot on, feel free to add story points to the process if that helps you estimate the delivery time better. But similar sized tasks and average cycle-times will probably give a similar range without the time put into estimation. I think that typically when using Kanban you would release when you see fit. So either you pick a date and release ...


6

Because Kanban is not a full framework for developing products in itself (it's a method to optimize another process), there are many things it doesn't specifically account for. However, teams often track throughput in either item count or even story points if they chose to use them. You can forecast release timelines with either item count or story points ...


0

Why are you asking us? It's your team, your company, and your process. We, strangers on the internet, can give general guidance, but we can't tell you what would be best for your specific situation. As for that general guidance? I can give you three pieces of advice: Give the team control of defining the workflow, both initially and changing it as more is ...


0

If this is a document that would be given to the client, then the business case and hence the strategic alignment should be from the client's perspective. The client should have little interest in how the work fits within the agency's plans or strategies short of being content that the agency wants to do the development work and provide any subsequent ...


1

I would align the project with the strategic plan of the customer. In order for a project to be perceived as useful and valuable, the project has to deliver something that advances the strategic aims of the client. Right now I'm working with a project client who has defined their project in terms of ensuring resources are available for the organization, but ...


Top 50 recent answers are included