Return to Answer

To fix this establish it as the norm that the standup simply says what you are doing. It is perfectly OK to give a standup report that says "I'm working on the export to PDF feature, and I expect to continue that tomorrow." If the task is expected to take a few days, that it's absolutely fine if that is the report for all of those days. It's also OK to say "I'm designing the export to PDF feature. I should be done with that tommorow and I'll start coding."

It's also very important not to focus on how many stores each individual person completed. The focus should be on whether the team completed its commitments as a team. The scrummaster should emphasize this, and avoid any discussion or measurement of how many stories each person moved.

The second problem is the picking up of low hanging fruit. It's a natural thing to happen if everyone's goal is to look good at standup rather than complete good work. But it is not the way scrum should work. You should prioritize the tasks within the sprint, and you should prioritize the big tasks highest, so someone should pick up the big difficult tasks on day 1. In any case, if by day 2 of the sprint nobody has picked up the big complex task, then the scrummaster should say "I see nobody has started the database compression task - that's a big task and it needs to be started right away if we are going to finish it this sprint". If nobody offers choose your best developer and say "Cecil, can you pick that one up please." Don't forget to congratulate Cecil at the end of the sprint for doing a good job.

One thing you didn't say but I suspect is relevant: it's the responsibility of the development team to keep the code quality up. If the developers are doing a slapdash job, find ways to make them do a better one - but remember that Scrum is at most a contributary factor here. Lazy developers (or developers who think they are under pressure) will do a crappy job in any development methodology.

To fix this establish it as the norm that the standup simply says what you are doing. It is perfectly OK to give a standup report that says "I'm working on the export to PDF feature, and I expect to continue that tomorrow." If the task is expected to take a few days, that it's absolutely fine if that is the report for all of those days. It's also OK to say "I'm designing the export to PDF feature. I should be done with that tomorrow and I'll start coding."

It's also very important not to focus on how many stories each individual person completed. The focus should be on whether the team completed its commitments as a team. The scrum master should emphasize this, and avoid any discussion or measurement of how many stories each person moved.

The second problem is the picking up of low hanging fruit. It's a natural thing to happen if everyone's goal is to look good at standup rather than complete good work. But it is not the way scrum should work. You should prioritize the tasks within the sprint, and you should prioritize the big tasks highest, so someone should pick up the big difficult tasks on day 1. In any case, if by day 2 of the sprint nobody has picked up the big complex task, then the scrum master should say "I see nobody has started the database compression task - that's a big task and it needs to be started right away if we are going to finish it this sprint". If nobody offers choose your best developer and say "Cecil, can you pick that one up please." Don't forget to congratulate Cecil at the end of the sprint for doing a good job.

One thing you didn't say but I suspect is relevant: it's the responsibility of the development team to keep the code quality up. If the developers are doing a slapdash job, find ways to make them do a better one - but remember that Scrum is at most a contributory factor here. Lazy developers (or developers who think they are under pressure) will do a crappy job in any development methodology.

The second problem is the picking up of low hanging fruit. It's a natural thing to happen if everyone's goal is to look good at standup rather than complete good work. But it is not the way scrum should work. You should prioritize the tasks within the sprint, and you should prioritize the big tasks highest, so someone should pick up the big difficult tasks on day 1. In any case, if by day 2 of the sprint nobody has picked up the big complex task, then the scrummaster should say "I see nobody has started the database compression task - that's a big task and it needs to be started right away if we are going to finish it this sprint". If nobody offers choose your best developer and say "Cecil, can you pick that one up please." Don't forget to congratulate Cecil at the end of the sprint for doing a good job.

(By the way, someone should check with the managers as to whether they are really being judged if they don't move a story across the board every day - it's not unknown for developers to think they need to achieve something every day while management is actually wanting them to do the right thing.)

The second problem is the picking up of low hanging fruit. It's a natural thing to happen if everyone's goal is to look good at standup rather than complete good work. But it is not the way scrum should work. You should prioritize the tasks within the sprint, and you should prioritize the big tasks highest, so someone should pick up the big difficult tasks on day 1. In any case, if by day 2 of the sprint nobody has picked up the big complex task, then the scrummaster should say "I see nobody has started the database compression task - that's a big task and it needs to be started right away if we are going to finish it this sprint". If nobody offers choose your best developer and say "Cecil, can you pick that one up please." Don't forget to congratulate Cecil at the end of the sprint for doing a good job.

Let's answer that. You list a number of problems that your team is seeing, and while they are not the fault of Scrum they are problems that Scrum is unfortunately prone to. Fortunately none of them are unsolvable within the Scrum framework, given the goodwill of the team and competent management.

Let's answer that by actually giving you some recipes for reducing these problems. You list a number of problems that your team is seeing, and while they are not necessarily caused by Scrum, they are problems that Scrum is unfortunately prone to. Fortunately none of them are unsolvable within the Scrum framework, given the goodwill of the team and competent management.