I know! But bear with me, we’re almost there, I promise. Our previous article can be found here. There are still some more rules to cover, but we are nearly at the end.
So, let’s have a look at more rules.
Multiple Developers can work on one User Story.
This is totally possible, and I’ll tell you why. First of all, the delivery of the Sprint Goal is a team commitment, not an individual Developer’s commitment. And, since the team should be cross-functional, they are all able to pull from the backlog. All the skills required lie in the team, so they do not have to ask anyone external for help. Within the Sprint Backlog, it makes sense, right? But this can also happen within the User Story. Imagine that you have a User Story that requires more than one type of skill to be delivered. In this case, more Developers can work on this User Story.
Or, you have a new team member and you need them to start working with the team and looking into the details. This is a way to involve them with some support from others, as opposed to working alone on a single User Story.
This doesn’t apply only to new team members. Current Developers that want to learn something new can join their colleagues and work together on one User Story.
In this case, I see the User Story as a tiny little Sprint. Because in the Sprint it makes sense that everybody is working together and helping each other.
But be careful. The devil lies in the details. And more about those below.
Only a single Developer can work on a Task.
So yes, more Developers can work on a single User Story, BUT only a single Developer can work on a Task. The reason is that Tasks belong to the Developers who are actually executing them. If more than one person works on the same Task, it would pose problems with synchronizing and updating the remaining hours left to finish the User Story. Also, each Developer can execute the User Story a little bit differently but with the same result, so Tasks reflect actions for the Developers that have concrete solutions. So, only one Developer can work on a Task.
Tasks are estimated individually in real hours to done (ETA) by the Developers who accepted the User Story into the Sprint.
Each Developer works at a different speed, so each one has to estimate their own Tasks. That gives them a better idea of how much work they have in the whole Sprint but also, by thinking about the Task and the time they need to spend on it, he or she has a better idea of what has to be done on the individual Task.
Tasks should ideally have a maximum size of 8 hours ETA.
Why 8 hours? Because basically 8 hours is a working day, and we should be able to execute the Task within one day. You should be able to complete your To Do list for a day from your Tasks. You start working on one Task, finish it, take another, etc. If you are not able to finish a Task within one day, you have to adjust the remaining hours left for the next day so we know the current progress on each day of the Sprint.
Ok! So that is these two rules. Four more and we are done with the rules for Perfect Planning. And then, another exciting topic.Thank you for reading!
Have courage and be kind.