15

It looks like Scrum doesn't address this issue in any way? No, it doesn't. Scrum is a guide. Although it prescribes stuff, it doesn't prescribe a lot of stuff. This is one of the things that are left at the discretion of the implementer. For ex, it used to provide a sample for 3 questions to ask during the daily, but those were dropped eventually (probably ...


11

I know there is an accepted answer, but I find it to have a bit of a trap in it, so I want to provide this answer for another view. I've been practicing Scrum for about 15 years and I have yet to encounter a task that could not be usefully broken down to less than a sprint. This has been in industries ranging from construction to marketing to research on ...


9

Estimates are a tool that supports planning. Anyone that needs to make decisions and build plans about the future can use estimates as a tool to make predictions and figure stuff out (without knowing for sure, you can only estimate; but having an estimate - any estimate - is sometimes better than not knowing at all). So for example: upper management can use ...


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 ...


6

First of all backlog items should not generally be "tasks" at all. Wherever possible backlog items should be deliverables, features or other outcomes. Do you have an example of a backlog item that cannot be split? Most big deliverables can be split. Consider a typical sprint consisting of 10 working days (2 weeks is probably the most common sprint ...


4

Since you mention sprint planning I will assume your team are using fixed-length iterations. Estimates are for the team. The team should include the senior stakeholder or the person who is accountable to stakeholders of course (e.g. the Product Owner), but the main purpose of estimation is to allow the team to decide what can go into a given sprint. The ...


4

Using the team's velocity as a guideline does not seem right because then the backend developers might end up with more work than the frontend developers or the other way around. What a lot of teams will do in this situation is to estimate in story points as a team, but then sanity check that they aren't overloading one particular specialism in the team. ...


4

Individuals don't have velocity, teams have velocity. Even if you have two roles in the team (backend and frontend), with some people unable to do other people's work, it's still the team as a whole that delivers work. Can you deliver only the backend to the user, with no frontend? Or the other way? No. So the sum of all the story points delivered in a ...


3

Further complicating the real-life situation is that there can be complex dependencies among the identified tasks, reflecting the architecture of the underlying system. Scrum is, and can only be, a guide. Take it for the many very-good ideas that it contains, but don't worship it.


3

Just another perspective... In the organization where I am currently employed no one "consumes" the estimates, and everyone knows that. Yet, we are still pointing stories/tasks. The goal of the exercise, for this organization, is not the points, rather it is the discussion to create a shared understanding about the work items, and it is the ...


2

And, here's a "sly" way of looking at it: when you're tasked with making an estimate, and if you actually try to do it, then it means that you're looking at things like "potential work breakdowns" and "dependencies." Maybe the actual number that you come up with is accurate, and maybe it isn't, but the process by which you ...


2

Estimations are a means for a goal. The goal, in this sense, is predictability. Who needs predictability? Pretty much everyone involved in the process, for different reasons. Example practices include planning poker, sprint planning, game plan development. In the above statement you're assuming all the above activities (amongst others) have the same ...


2

All stakeholders involved should be consuming estimates. Without estimates, there is no way to arrive at planning values. Without planning values, there is no way to make a cogent decision because there is no way to evaluate investments, divestments, progress, benefits, costs, and risks. All of those things require estimating. And every stakeholder has ...


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 ...


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 ...


Only top voted, non community-wiki answers of a minimum length are eligible