Dilemma - Story points or Capacity ? What should be considered while work allocation?
In our first sprint , we considered story points as below:
1- Low 2-Medium 3- High & So on... (Here story points indicate complexity, Risk and efforts involved)
We calculated capacity (number of hours available) for that sprint, though we never used it . Development team members also did not enter estimated time/remaining time for tasks. Each development team member took 5 story points and it was decided that in the upcoming sprints we would increase story points /developer till the time we would get to know how many story points of work we can complete.
When first sprint was going on, I got to know that it is mandatory for all development team members to enter estimated hours/remaining hours for each task and also there should NOT be any relation between story points and hours . (Example- 1 story point= 2 hours ). Requirement to enter estimated/remaining hours is only for tracking purpose and all other projects are following the same.
Our first sprint has ended.
Now, in 2nd sprint my dilemma is - :
1. Should we assign work as per what we decided in first sprint ? That is, by increasing story points to see how many story points we can deliver as a team? So, as I mentioned above in last sprint each development team member took 5 story points of work. So, in this sprint 7 story points of work should be taken by each development team member.
2. OR, since we will be mentioning hours for each task, should we assign work by comparing capacity of team member (number of hours available in the sprint) and sum of estimated hours filled for tasks related to that particular developer?
3. Any other approach ?
Vishal,
A number of questions/concerns regarding your post:
Each development team member took 5 story points
It seems from the above statement that your Development Team is accepting work in silos. If that is true, it is not a formula for collaboration and teamwork (it represents more of a "working group" than an actual Development Team). Is the Development Team prepared to continue work done by another team member if they become unavailable for any reason (i.e. - illness, personal emergency, etc.)?
it was decided that in the upcoming sprints we would increase story points
Why was this decision made? If I understand correctly, you are starting with a new team in their first sprint. What evidence do you have that the team can increase the amount of points forecast after the first sprint? Is there a possibility that the team may even need to reduce the amount of points forecast?
it is mandatory for all development team members to enter estimated hours/remaining hours for each task
Who requires this data, and why? Even if this practice only supports "tracking purposes", it is still a clear sign of a lack of trust. What can you do as a Scrum Master to promote better trust between the organization and Scrum Teams?
After the first sprint, did the team meet their Sprint Forecast and Sprint Goal? Wouldn't this weigh heavily into a Development Team's determination around the amount of story points forecast for the 2nd sprint?
And you should refrain from any reference to "assigning" work. It should be left solely up to the Development Team to determine how much they feel comfortable taking on each sprint.
Hi Vishal,
Sprint goal, sprint backlog (story selection), commiting work as per velocity, are done at team level and not at individual team member level. So taking 5 story points by each team member may defeat agile principles - Colloboration and accountability (team will win or fail).
In my opinion, using capacity with team velocity during planning make sense sometimes and sometimes capacity may not required. If you have dedicated team with no change in team size, team members and have no holidays/leaves, then you can consider velocity to decide how much team can commit for sprint. If have no dedicated team or have holidays/leaves, then relook or adjust your velocity with available capacity.
Might it be better to improve teamwork and focus, so the timely completion of backlog items is better demonstrated?
For example, what might work item age suggest to the team about their discipline and sprint control?
It seems from the above statement that your Development Team is accepting work in silos. If that is true, it is not a formula for collaboration and teamwork (it represents more of a "working group" than an actual Development Team). Is the Development Team prepared to continue work done by another team member if they become unavailable for any reason (i.e. - illness, personal emergency, etc.)?
Yes.. I have to accept that we work in silos.
But I have a query here- How can we avoid working in silos???. Say we have user story 1, user story 2 and user story 3. Each is taken care by individual developer. Now, to not to work in silos, we can ask 2 developers to work on user story 1. We will remove user story 3 from sprint. But still, third developer will have to work on user story 2 alone. All 3 developers cannot work on single story right? Really need help on this.
Why was this decision made? If I understand correctly, you are starting with a new team in their first sprint. What evidence do you have that the team can increase the amount of points forecast after the first sprint? Is there a possibility that the team may even need to reduce the amount of points forecast?
The reason is they could complete all story points in first sprint (5*3 developers=15 points). Now we want to see how many more points of work we can accommodate in a single sprint ?
Who requires this data, and why? Even if this practice only supports "tracking purposes", it is still a clear sign of a lack of trust. What can you do as a Scrum Master to promote better trust between the organization and Scrum Teams?
As I got to know client needs it as client pays based on hours and top management has requested us to follow this practice ..As a scrum master it's beyond my control to convince and change this practice. As you rightly said it indicates lack of trust,for the first sprint even I opposed for this left and right . But I have seen that some of the development team members were actually wasting time and pushing work till end of the sprint. So, yes, there is a trust deficit because what I observed in first sprint.
In my opinion, using capacity with team velocity during planning make sense sometimes and sometimes capacity may not required. If you have dedicated team with no change in team size, team members and have no holidays/leaves, then you can consider velocity to decide how much team can commit for sprint. If have no dedicated team or have holidays/leaves, then relook or adjust your velocity with available capacity.
Makes sense.
Sprint goal, sprint backlog (story selection), commiting work as per velocity, are done at team level and not at individual team member level. So taking 5 story points by each team member may defeat agile principles - Colloboration and accountability (team will win or fail).
Our development team members work in silos as before we started sprint, each development team member was doing analysis or working on different different problems. So once we started sprint, story related to that problem was assigned to that particular developer. Now I am not sure how we can come out of this situation.
Might it be better to improve teamwork and focus, so the timely completion of backlog items is better demonstrated?
Yes. We are working on it.
*** But I have a query here- How can we avoid working in silos???. Say we have user story 1, user story 2 and user story 3. Each is taken care by individual developer. Now, to not to work in silos, we can ask 2 developers to work on user story 1. We will remove user story 3 from sprint. But still, third developer will have to work on user story 2 alone. All 3 developers cannot work on single story right? Really need help on this.***
My best understanding as per your explanation, I think your team is working on iterative waterfall model. Agile-Scrum expects cross functional team perform design (if applicable), development (like presenation/UI layer, business & data layer) and testing activities for every story in a given sprint. Plus it may have some other tasks like reviews, deployment etc., You mentioned 1 developer working on 1 story, possiblly he/she may working few of story development tasks and not all. Please correct me if I have any misundertanding.
We do some of these activities during backlog grooming, use splitting tecniques for Story like SPIDR, MoSCow, Story Slicing etc., And story follows I.N.V.E.S.T and will try to make story as small as possible for team to perform above given tasks in single sprint. Other important point, during Sprint planning, select stories with mixed sizes (like majority are smallers ones then medium & high ones next) and try to complete smaller one first, so that test execution can start for them and team will have work till end of the sprint.
Please google it to find more details about INVEST, Story spltttng, slicing and cross functional teams.
Should we assign work as per what we decided in first sprint ? That is, by increasing story points to see how many story points we can deliver as a team? So, as I mentioned above in last sprint each development team member took 5 story points of work. So, in this sprint 7 story points of work should be taken by each development team member.
>> What is the reason for equal story points splitting between developers ? does all developers needed equal efforts to finish 5 SPs? what do you think about team collaboration when developers focus towards completing 15 SPs in a Sprint than working on 5 SPs each ?
Our development team members work in silos as before we started sprint, each development team member was doing analysis or working on different different problems. So once we started sprint, story related to that problem was assigned to that particular developer. Now I am not sure how we can come out of this situation.
>> What does you DOD say ? does it involves review and test ?