-1

We have a team of about four developers working in Scrum with two week sprints. We use YouTrack and when performing time estimation in Sprint Planning, we hit the two weeks of work quickly.

The issue is, for example, developer John will pick the first item on the backlog and say it'll take about 1 day. Developer Brian will take the next item and say it'll be about 1 day. Of course, that's actually only one day's work if each developer works on each piece, but YouTrack will sum it as 2 days.

When the whole team doesn't have to work on the same item at once, how do we appropriately estimate time? Are we breaking Scrum rules somewhere?

If we're doing it right, and we have to just go over two weeks, how do we be sure we're not giving ourselves too much work?

Filburt
  • 17,626
  • 12
  • 64
  • 115
clydebank
  • 11
  • 1
  • 1
    As far as I know and understand, you don't estimate effort in Scrum. You estimate complexity of user stories in relation to each other and the contained functionality. – connexo Jul 28 '15 at 07:55
  • Understood, but the same applies then for complexity. Looking at Planning Poker for example, I'm confused at how a group of developers able to work on separate items can estimate what will fit in to a two week sprint or not. – clydebank Jul 28 '15 at 07:59
  • That evolves over time. You estimate *story points*, then the *burndown chart* shows your progress. Over time you get quite an accurate *team velocity* which basically tells you how many story points your team gets done with per *sprint*. – connexo Jul 28 '15 at 08:08
  • This question is off-topic because it's not within the scope for this site, as defined in [What topics can I ask about here?](//stackoverflow.com/help/on-topic) Also see: [What types of questions should I avoid asking?](//stackoverflow.com/help/dont-ask) You may be able to ask on [another Stack Exchange site](//stackexchange.com/sites#name), for example [pm.se] or [softwareengineering.se]. Be sure to read the on-topic page in the help center for any site on which you intend to post a question. – Makyen Oct 01 '17 at 01:53
  • 3
    I'm voting to close this question as off-topic because it is not about programming. – Vadim Kotov Oct 23 '17 at 08:35
  • I'm voting to close this question as off-topic because [project management is now off-topic on Stack Overflow](//meta.stackoverflow.com/questions/343829/is-stack-overflow-an-appropriate-website-to-ask-about-project-management-issues/343841#343841). Ask these questions on [SoftwareEngineering.SE](//softwareengineering.stackexchange.com/) and [ProjectManagement.SE](//pm.stackexchange.com/) instead. (You can also flag for moderator intervention to have this question migrated.) – robinCTS Oct 28 '17 at 01:47

3 Answers3

1

It should NOT be only Complexity but include Complexity, Effort, Risk and a gentle touch of common sense.

I think you are estimating in the wrong way to begin with, which has nothing to do with Scrum, Kanban or XP. You are estimating in a per person basis which should be actually done on per Story basis. Think about the feature as a whole and then estimate the story and not individual member's effort towards it.

Estimating by man days/hours have always been criticised as it doesn't involves the skill set measurement. Say, one feature with complexity 5 can be done in 1 day by a senior engineer but it will take 2 days for a new joiner or less experienced member. Hence, you can't take only complexity into account to measure the story sizes and sprint commitments.

Many people estimate Stories using complexity only and then sub-tasks according to hours, that has drawbacks as well due to duplication of effort in the actual estimation. Above all, always keep in mind that an Estimate will always be an estimate and Planning poker can only help you find it but it is not the ultimate estimation technique.

swaggapride
  • 11
  • 3
1

Adding my five cents here, complexity of the backlog items is not judged by individual team members.

First of all, a backlog item most likely involves more than a single team member and could be broken down to smaller tasks like 'implement UI', 'run tests' or 'change the database schema'. So there will be both John, Brian and maybe also Mary (a testing engineer) involved. And thus you'll need to estimate 'Complexity, Effort, Risk and a gentle touch of common sense' for the whole team, not just for John or Brian.

Also John, being a senior guy, might say it is of complexity 2, while Brian (a junior) could say it is 5 and Mary will notice a lot of regression because of the database schema change and give it 8. In the end in Scrum it comes to the whole team's commitment for the sprint. So you, as a Scrum Master, will need to facilitate John, Brian and Mary to come to an agreement and here's where tools like planning poker come to the stage.

bopcat
  • 378
  • 4
  • 13
0

As far as I know and understand, you don't estimate effort in Scrum. You estimate complexity of user stories in relation to each other and the contained functionality.

Following this, you estimate story points, not man days. The burndown chart shows your team's progress. Over time you get quite an accurate team velocity which basically tells you how many story points your team gets done with per sprint.

Use this team velocity as a basis to decide whether to commit to another user story for any given sprint, or if it will probably be too much.

connexo
  • 53,704
  • 14
  • 91
  • 128