Unit for estimating hours in Scrum tool [closed]_问答_开发者

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

This question does not appear to be about programming within the scope defined in the help center.

Closed 5 years ago.

开发者_StackOverflow中文版 Improve this question

I've been learning Scrum and trying a tool called Acunote for use with it. My question is about two fields I have there, for each task. They're "estimate" and "remaining". What unit should I use for those? Do I use Story Points? What about the remaining? For example I have a task that will take 10 units, let's say. I fill the remaining at the end of day with how many "units" I believe it will take me to complete?

Thanks!

I have a few suggestions for you:

If you are new to scrum; use a whiteboard and don't get bogged down in a particular tool's semantics; it will hamper your learning and adoption.
Break your stories small enough so that you don't have to create and estimate Tasks.
Don't do anything with hours, it is a waste of time to estimate at that level.
Burn down story points.

It is all too easy and common for teams to "think" they are on track because Tasks are being completed and burned down. Then they get to the end of the sprint and find that 5 stories are all 90% done and nothing is completed. If you burn down stories you are actually tracking deliverable business value and not just an arbitrary amount of developer-junk.

As always, my first advice would be to not use a tool when adopting/learning Scrum (I start to be tired to repeat the same thing over and over :). Instead, start with the simplest thing that could possibly work (a spreadsheet for the Product Backlog, a white-board and post-it notes for the Sprint Backlog). The rationale behind this is that you want to learn and master Scrum, not a tool. So don't let a tool tell you how to do Scrum and drive the process.

Then, regarding the question, there are 2 schools of thought: 1. what Scrum says in theory, 2. what some people do in practice.

In theory, Scrum has two levels of estimation: one for work (Tasks) to be completed within the current Sprint and one for more distant Product Backlog Items (PBIs). At the Product Backlog level, items (the "what" is being built) should be estimated in Story/T-Shirt/Unit-less points which have a low degree of precision. This approach avoids "analysis paralysis" pitfalls and accurately reflects the general uncertainty surrounding the work in question. At the Sprint Backlog level, items are beaked down into tasks (the "how" a PBI will be achieved) that are estimated in hours. A separate estimation scheme is appropriate because Tasks describe granular work (usually on the order of a few hours, never more than 16h). In fact, Scrum recommends using "ideal engineering hours" for Task-level estimates.

In practice, some people don't estimate in hours because burning down hours doesn't show "real" progress, which isn't false, and they prefer to burn down Story Points (which really means an item is done or not, it's more binary).

While I understand the "spirit" of the later approach, I don't apply it and stick with the theory. Actually, for the reasons previously mentioned, estimating in hours does make sense to me and I actually find that it gives better "control" of the Scrum empirical process during a Sprint (at the end of each day, you should update the estimated remaining work regardless of the actual time spent and this is easier with hours).

Moreover, I don't like the drawback of having only small stories (which can be seen as waste too) but like when a team identifies clearly what has to be done within a Sprint (this is good for transparency and helps the Product Owner to understand the real amount of work too, especially "quality oriented" tasks).

Finally, I think that you can avoid the pitfalls mentioned by DancesWithBamboo with hours too. Just stay vigilant and:

Always focus on the most important PBIs (and related tasks) first.
Pay a special attention to non-finished tasks, they should keep moving on the white board (if you are using columns to represent steps like for example "todo", "in progress", "to be verified", "done"); a non moving task is a smell.
Don't start a new item before the previous is done.

So, in my opinion, it is possible to use hours and to avoid the "nothing done" at the end of the Sprint syndrome. Just use your brain (Scrum and/or any tool won't replace it, luckily for us).

Having that said, and if you don't throw your tool away, the questions to answer are: what do you want to show on the burndown (points or hours depending on if you breakdown the work into tasks or not, I gave you my point of view) and what field does Acunote use to draw the burndown (i.e. where should I update the estimation of the remaining work). If you choose points and don't use tasks, it wouldn't make sense to update remaining work unless it's totally done IMO (a PBI is done, or not).

IMHO you shouldn't use remaining for the SCRUM points, because the points should be really subjective and you probably can't say how far you have gone. I would recommend that you break the task into smaller ones (these ones would be the steps you need to implement the features) and then estimate them into hours. This way you can easily track the progress of the feature

Use hours for both the initial estimate and the remaining time. Tasks are usually estimated in hours.

You can use Scrum point - or any other unit - to estimate the backlog items.

I would not bother with remaining. A story or a task is boolean (either done or not done). In our team we started to accept only tasks that are expected to have less than a day. That way no team member should be working on the same task on two consecutive daily scrums. The third day for sure rings alarm bells! Also breaking up in task is easy and fast, because it doesn't take much estimating. Is it less than a day: OK, otherwise break it down.