Clarity needed on work assignment

1. Since our sprint planning happens in the evening , one day goes waste as no work is "officially" assigned to developer till evening (sprint planning). How to deal with this issue? In your team how you deal with this?

In Scrum, a team ought to be self-organizing. Is this evening arrangement their choice? If it isn't, then the inability to self-organize is the problem which ought to be addressed. On the other hand if it is their decision, then why have they made a sub-optimal choice which incurs the waste you describe?

2. BA shares which stories are on priority for the coming sprint and developers do not have a say in it. (Except, if there is any technical reason not to work on that particular story).  Do you think this is the right approach?   

Shouldn't it be the Product Owner who makes prioritization decisions regarding work on the Product Backlog? Shouldn't developers have a say in what work is planned into the Sprint Backlog? What does the Scrum Guide say about this?

3. Development team is divided into onshore and offshore team members. So, even if they decide to collaborate and decide who is going to work on which story, it can only happen during sprint planning (That is in the evening). So the team will be idle for entire day. What should they do during this time?

Who divided the team into onshore and offshore elements? Did the team themselves decide to do that, or was it some external authority? Whoever it was, are they aware of the consequences of this decision in terms of utilization and idle time, and do they consider it to be acceptable? What has been done to make this matter transparent?

1. Since our sprint planning happens in the evening , one day goes waste as no work is "officially" assigned to developer till evening (sprint planning). How to deal with this issue? In your team how you deal with this?

This is an extreme example, but yeah, I've been on teams where there's some time between the events at the end of one team and the Sprint Planning for the next Sprint. Usually the devs try to do something productive during the time, either tending to infrastructure, or starting work on a high priority item which is sure to be in the next sprint (if the backlog is stable enough to make that call). It's never a whole day, though. Did I understand correctly, that this is a timezone issue for you?

2. BA shares which stories are on priority for the coming sprint and developers do not have a say in it. (Except, if there is any technical reason not to work on that particular story).  Do you think this is the right approach?   

It's quite normal for the PO to decide on the priorities of Product Backlog Items. In this case, the BA seems to be doing that job for him, which may not be ideal, but still okay. However, the development team are the only ones who can decide which of those PBIs can be included in the Sprint Forecast.

3. Development team is divided into onshore and offshore team members. So, even if they decide to collaborate and decide who is going to work on which story, it can only happen during sprint planning (That is in the evening). So the team will be idle for entire day. What should they do during this time?

Why do they need to decide who's doing what during Sprint Planning anyway? Wouldn't the team be more flexible if developers pulled a new work item when they're finished with the last one? Otherwise, how would you deal with situations where an item takes longer (or shorter) than expected?

In Scrum, a team ought to be self-organizing. Is this evening arrangement their choice? If it isn't, then the inability to self-organize is the problem which ought to be addressed. On the other hand if it is their decision, then why have they made a sub-optimal choice which incurs the waste you describe?

 No Ian. Because of the geographical time difference we need to conduct sprint planning in the evening. Client has it's own developers as well. So, basically team has no choice.Our evening is their early morning. So that's the only time convenient to both the teams to have sprint planning. So, disbursed teams because of geographical locations is major impediment in self organization is what I realized. 

Shouldn't it be the Product Owner who makes prioritization decisions regarding work on the Product Backlog? Shouldn't developers have a say in what work is planned into the Sprint Backlog? What does the Scrum Guide say about this?

 

Scrum guide says that -  The work to be performed in the sprint is planned in sprint planning and this plan is created by the collaborative work of the entire scrum team. So, in our case we should immediately stop the practice of getting work before sprint planning. As far as developers having a say in the work that is planned in sprint backlog is concerned, they only have a say if they feel they won't be able to deliver because of XYZ reason. Else, they are okay to work on any work item. So, basically while accepting work development team think about - A. Capactiy  B. Technical competence  B. Dependencies (Example: If the required technical doc is present or not).  D. Time required to complete the story . If these 4 criteria get satisfied, they are okay to work on any item.

Are we missing on something ? Should the development team team think about any other points which may influence the decision to take the work in sprint?

 are they aware of the consequences of this decision in terms of utilization and idle time, and do they consider it to be acceptable? What has been done to make this matter transparent?

Client is very much aware about this. So, when I said team will be idle for entire day, I mean most of the team members. So, we basically use 50% capacity of the development team only on first day. It's not entirely 0 . While calculating capacity of particular developer we calculate like this : 10 days * 6 (hrs daily)=60 - 6 (For going through technical documents, calls, etc)=54 total capacity. So, client is loosing nothing. But it's not fair for technical team as they want to work from day 1 only. However, because of evening sprint planning they cannot. How can we solve this problem?

 Usually the devs try to do something productive during the time, either tending to infrastructure, or starting work on a high priority item which is sure to be in the next sprint (if the backlog is stable enough to make that call). It's never a whole day, though. Did I understand correctly, that this is a timezone issue for you?

Yes. As I mentioned above , we are utilizing 50% capacity on day 1 because of Timezone issue. 

Wouldn't the team be more flexible if developers pulled a new work item when they're finished with the last one? Otherwise, how would you deal with situations where an item takes longer (or shorter) than expected?

But, let's say we took 10 stories and we have 4 developers. Each is working one story. Now, since only one story is assigned to them, they are a bit more relax. They have not committed that work as an individual . So, they may just complete 4 or 5 stories by the end of the sprint. 

When the story is assigned to each developer, on back of his mind he knows he needs to deliver. So, he will be more productive. Other advantage I found is - : 

Say, we have there resources:

A- UI resource   - capacity for the sprint is 50 hours

B- Service resource - capacity for the sprint is 30 hours

C- Automation resource - capacity for the sprint is 30 hours

If we do story assignment in sprint planning itself, we will get to know something like - Resource A is available for 50 hours but we have taken just 20 hours of UI work. Resource B and C is available only for 30 hours, so for this sprint, instead of more service and automation work , let's take at least 40 hours of UI work.

This I will get to know only if I break down user stories into tasks in sprint planning. And this will influence my decision to take which type of work in sprint. 

This is just my opinion by looking at cons. I need expert advise. 

1. Since our sprint planning happens in the evening , one day goes waste as no work is "officially" assigned to developer till evening (sprint planning). How to deal with this issue? In your team how you deal with this?

Vishal, is there mistrust in your organization?   Do you not trust the team to use their available time wisely, in the interests of the business and their own proficiency and efficiency?   If not, why is that?

As an aside, are you sure that Scrum is the right framework for your situation?   There are other Agile approaches available that may be easier for your team and organization to practice.

2. BA shares which stories are on priority for the coming sprint and developers do not have a say in it. (Except, if there is any technical reason not to work on that particular story).  Do you think this is the right approach?   

As Julian previously stated, the development team must be the final arbiters of what is feasible to accomplish in the next sprint.   Think of it in terms of an "offer" and a "forecast".   The business (in this case, the BA) makes an "offer" to the team of the highest-priority work needed.   The Development Team then makes a "forecast" of work to be completed in the sprint based on the offer made.   Ideally, this will be 100% of the offer made, but the Development Team MUST be able to make that decision (work is pulled, never pushed, in Agile).

If the Team is not given this responsibility for determining what they're capable of completing in a sprint, is that another sign of mistrust?   (see response to #1)

On another note, why are you spending so much effort trying to utilize each member of the Team?   Agile is all about Team Ownership of forecast work.   The Development Team must be allowed to plan completion of that work as they see fit.   Ultimately, the sprint work is owned by the team, not by specific individuals, regardless of their expertise or specialization.   There is no assigning of work in Scrum by those outside of the Development Team.

Think of this another way.   If an item is "assigned" to a certain individual, and that individual suddenly becomes unavailable (i.e. - illness, personal emergency, etc), what happens to that item?   Is the Team still positioned to complete that item in the absence of that individual?   If so, then good, and perhaps their Sprint Forecast needs to be reviewed in their Daily Scrum to determine if they are still capable of meeting all of it.   If not, then why not, and why is such a vulnerability embraced within this project?

How can we solve this problem?

You have already determined that the geographical dislocation of the team is a “major impediment in self organization”.

My advice is therefore to be very clear and honest with the client about whether there is a real desire to resolve this impediment, such as by having a co-located team.

If there isn’t, then that needs to be understood. Perhaps there is only an interest in working around impediments which are otherwise accepted.

Openness about this will be critical to any decisions made, such as whether or not Scrum can be implemented and the benefits obtained.

Thank you Julian, Timothy and Ian for your valuable time. 

I came to the conclusion that we are not using proper SCRUM. It's kind of hybrid agile.  Because of which, we are observing below problems :

1. Development team is not self organized and always relies on others for decision making (They just want to code)

2. Development team is not happy about the agile concept as they are under tremendous pressure as in sprint planning stories get assigned to each member in development team (By using the logic of capacity I have mentioned in last post) so by hook or crook they try to complete the work ; in some cases by affecting their personal life .. staying late in the office, missing tea breaks and what not.

3.Team has lost motivation to improve (Which I guess we can't expect from frustrated and over worked team)

This makes me think it's always better to adopt agile in totality or better use some other method. 

Thanks all.

Vishal,

The 8th Agile Principle:

Agile processes promote sustainable development.   The sponsors, developers, and users should be able 

to maintain a constant pace indefinitely.

Overloading the team, to the point that they miss breaks, stay late, and negatively impact their personal lives, is simply not Agile.   Teams must be allowed to work at a sustainable pace, instead of at a pace where burnout is imminent.   

Also, a more sustainable pace is inherently more predictable, and therefore provides the business with greater clarity over what can be achieved over a period of time.

@Timothy

well articulated. Noted !

I'm going to add one thing to this excellent conversation.

I am going to go out on a limb based on some of the things that @vishal has said and assume that he works for an offshoring company where other companies pay for the work(clients) and his company bills based on hours worked.  While Scrum can work in that model, the better way to do it would be for the clients to pay for delivered functionality instead of hours.  Yeah, that is more difficult to write up contracts for but it would be better suited for Scrum.  That way the Development Teams can feel less pressure to produce billable hours and can be freer to focus on the delivery of workable, high quality potentially shippable increments.

I think you may have arrived at the correct decision.  You aren't doing Scrum.  You are attempting to do some form of agile software development but even that is missing based on the sustainable pace issue you mentioned.  It sounds like you need to be having some serious discussions with your companies management about the problems and attitudes that are being arising with the Development Team.  In the end, fixing those issues will make your clients happier because it will mean quality is produced instead of just code.  I would also suggest you look less at Scrum and work out your own hybrid of multiple agile ways.  The Scrum framework makes it very possible to wrap it around other practices.  The real benefit that I see Scrum providing you is a cadence in which you can sync up billing activities. You can still do that in other ways. 

Good luck.  You have a difficult road ahead of you.