6

I do 1 week sprints with my scrum team, and every Monday I do a sprint planning where my team estimates by allocating story points to the cards, this then allows me to measure the progress of a sprint in a burndown chart. The trouble that I am having is that whilst one of the two developers is quite good, the other is struggling to complete the work to meet the sprint goal. It has been a couple of weeks now where we have missed the sprint goal.

I want to help him improve, but not sure how - I have already put him on a training schedule, which he completed but he is lacking a lot of commercial experience. What is the best way to deal with this?

5
  • 2
    You can't allocate him more work than he can handle!!! People work faster with experience, not with pressure to meet unrealistic (for them) goals. You need to adapt to him, not the other way around. Mar 16, 2016 at 15:41
  • Yeah I understand, so how do I adapt this in an environment where I have extremely tight deadlines - a client needs x work done by y date? I am implementing agile in an agency environment.
    – bobo2000
    Mar 16, 2016 at 15:44
  • 8
    So you've been consistently missing your commitments, but haven't felt the need to alter the amount of work you commit to?
    – Nathan
    Mar 16, 2016 at 23:42
  • @NathanCooper good point
    – bobo2000
    Mar 17, 2016 at 11:37
  • 1
    Are you actively doing sprint retrospectives after each sprint? This should help you find out what the team experienced that prevented them from realising their full potential. In addition, my personal experience suggests that 1 week sprints are a little short, you might want to check with the team whether it feels fine or if they might want to try 2 week sprints instead. In my personal experience, with 1 week sprints a relatively large amount of time is lost on the 'overhead' (planning, retrospective, backlog grooming, etc) making it feel like you don't have a lot of time to get things done.
    – Cronax
    Mar 21, 2016 at 9:49

6 Answers 6

11

You shouldn't be allocating story points to cards. The team should estimate the cards and agree on what to pull from the backlog based on their velocity.

The team is accountable for making their own forecasts and sprint plans. You telling them what must get done in the next week is neither Agile nor Scrum. You're also likely demotivating your team members and hurting their longer term productivity. For yourself, you're fooling yourself that assigning people work will ensure it gets done according to schedule. You're also blinding yourself to see in advance what is more likely to get done and what is not when you don't let the people that will actually do the work tell you what they think they can get done.

A very common way to ramp people up is to have them pair with a more experienced developer. So instead of Joe and Bob working on parallel stories or tasks, they spend the entire day working together in series. One story or task at a time. This is one form of XP pairing, you can read lots about it on the web.

You will take a short-term productivity hit in return for a shortened ramp and longer-term effectiveness and/or efficiency gains. Pairing also does wonders for your product quality, team communication, and continuous improvement.

2
  • Sorry - edited my OP, they estimate the cards, I don't. The pair programming sounds like a good approach, ironically I decided to introduce that earlier today. Thanks for confirming it.
    – bobo2000
    Mar 16, 2016 at 15:57
  • To add to this otherwise good answer, I would mention that in agile, it's alright for some sprints to fail, especially the first few. The team needs to ramp up and get used to the project and the process, so in the beginning their estimates will be off. After a few iterations with proper sprint retrospectives each time, the estimates should become more accurate and the velocity should start to stabilise.
    – Cronax
    Mar 21, 2016 at 9:53
4

I do 1 week sprints with my scrum team, and every Monday I do a sprint planning where I allocate story points to the cards

Maybe you should either read a book or take a course on SCRUM. What you are doing is not SCRUM. Or in any way agile. You tell your people what to do and you tell them how long it will take them. Your are not a team. You are the boss and you have employees.

If you want to do SCRUM, have your team estimate and plan. They are the guys that have to do it, they should tell you how long it will take.

6
  • I do the planning together with my team in the Sprint planning session where THEY ESTIMATE based on the complexity of task relative to others. Part of the problem is that they may estimate, but when it comes down the nuts and bolts of the work, the original estimation that they have given me is inaccurate since it took longer than expected.
    – bobo2000
    Mar 16, 2016 at 15:49
  • @bobo2000 Isn't that the point of an estimation? That it's never really correct?
    – nvoigt
    Mar 16, 2016 at 16:00
  • sure, the problem is though when they are so way off their initial estimation that it is ringing alarm bells. Not sure if you can plan properly if the team isn't delivering work in a timely manner
    – bobo2000
    Mar 16, 2016 at 16:02
  • 1
    The story point system should be self-correcting. If they always estimate hard tasks at 1 storypoint and then take 4 weeks to deliver, the next card with one story point will take 4 weeks in their current velocity. Do you track velocity and use it for sprint planning?
    – nvoigt
    Mar 16, 2016 at 16:07
  • Yes, I use the sprint burn down chart to track velocity and at sprint planning have tried to manage my team's expectations based on it by not taking too much on. I think the problem is tbh one of the developers is struggling to do the tasks from a skill perspective.
    – bobo2000
    Mar 16, 2016 at 16:30
4

Let's try and step back from agile/not agile...scrum/not scrum perspective.

Breaking this down simply, if they're getting work done but just not getting done as much as they thought they could, I think that's pretty normal. Estimating in a room with other people of all perceived skill levels causes us to try and overestimate to compensate for our inherent insecurities.

If the team is getting things done, try and focus more on keeping the work interesting for everyone on the team and make sure everyone is having fun.

If the team has a clear vision of the project, then you could move to using the stories more as a tracking mechanism instead of "commitments". This would give you the ability to track velocity and estimate project completion time, while not destroying moral of the team.

From an economist perspective a worker could just commit to a single, easiest, lowest point story that's available each week to maximize the chances of them meeting the goal.

The way to counter this is really to try and keep people excited about what they're working on. Even if it's a mundane task, try and pay attention to what motivates each member of your team and even meet with them individually and ask them what would make them more excited about the project.

Just my $0.02. I've been a software engineer for 12 years and I've spent a lot of time working with PMs to help them solve this exact problem.

1

Face facts. This guy isnt going to magicaly get more productive because you have a deadline. Get more devs on the team and be glad for the ones you have.

Everyone wants delta force for their mission; but you have to work with what you've got.

0

If you are practicing Scrum, the problem isn't that one programmer is "struggling to complete the work to meet the sprint goal." The problem is that the team is struggling to meet the goal. The cause of that struggle may be a lagging team member, the problem belongs to the team, not the individual.

Your first priority, then, should be to get the team to do a better job estimating what they can do based on the resources that they have. If the team knows that one team member is lagging behind, they need to account for that. If you've been accurately tracking your velocity you should be aware that your velocity is smaller than what you are using for planning purposes.

If you find that the team is consistently missing their targets by 20%, simply take that into consideration when doing your planning. That can easily be accomplished by choosing to do one or two less points per sprint.

In the mean time, if during the retrospectives you find out that one team member isn't pulling their weight you can work on solving that problem as a separate effort. Perhaps have a senior dev pair with them, or perhaps you need to move them into a different role or give them more training. Regardless of the solution to that problem, you must separately address the problem of the team making bad estimations.

1
  • Fair enough, good answer.
    – bobo2000
    Mar 18, 2016 at 16:14
0

As others mentioned, scrum is a team effort. Although in reality, there will be some sort of barrier/separation but it shouldn't look like they are horses on a race track focusing only on themselves going through the finish line. How high that barrier is depends on the attitude/ego of the programmers. Pair programming is a good way to lower this barrier, unless one of them is not a team player then that will be a tough setup. also, do a retrospective to evaluate the sprint. If you weren't able to identify root cause of the issue then do a one to one conversation, could it be that he uncovered somethings on the backlog which weren't anticipated such as off specs or he underestimate the tasks.

I dont know how's the setup of the two programmers but i had been in the same situation long time ago. To cut the story short, i need to integrate another programmer's work (other programmer is not a good team player worse is that he wants to go to the next sprint in advanced as soon as he finishes 'his' sprint backlogs), whenever he says the done, the management will just go "wow". Upon integration, some codes do have some bugs, lots of copy pasted sections, unnecessary excess and wrong usage of oop concepts/design patterns. Being done is not just about being done, it must be done, written well, tested and in an acceptable quality.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.