Question from my developers- What shall we tell in daily scrum?

Instead of being focused on "continuing", they should focus on "finishing".

You work/continue working on PBI / task ABC without any impediment. Great. How far are you from being "done" ?

Vishal, when you have a "Working Group" that are separately working on disparate items in silos, it is quite difficult to help them understand the benefit of a Daily Scrum, sharing information, and collaboratively developing a game plan for that day.

Just curious - why do you think this "group" doesn't see value in sharing progress on what they are working on?   Why do they seem to be treating the Daily Scrum like a status meeting?

@Vishal, I think @Timothy has the right answer. In my past experience if everyone is working on separate stories and only one person per story it isn't easy for people to see the benefits of the Stand Up.  In fact it is difficult for them to see the benefit of Scrum in general.  Scrum is most effective when the individuals in the group work together to get work done.  For example, look at a soccer team.  If each player tries to take the ball all the way to goal every time, the team probably won't win many games.  They have to support each other, pass around.  Sure one person might be able to take the ball all the way down the field but that is going to be the exception and not the rule. 

Look for signs where one or two of the developers are having issues completing work during a single sprint. Even if it isn't the same developer every time, having it occur often is a red flag.  If you see someone that has been working on an story for more than 2 days, start asking for specifics on why it has been so long?  Or even better, ask someone else in the group if they know why there hasn't been progress.  Ask if the group has any concerns about everyone finishing their work.

Make sure that the group creates a Sprint Goal.  At each Stand Up after everyone has said "I'm still working on the same story" ask if anyone feels the Sprint Goal is still achievable.  Sometimes that can help people to start caring about what others are working on. 

 I am working on ABC user story ... I will continue working on ABC user story

A User Story is typically a Product Backlog item. However A Sprint Backlog is more than a collection of such items; it also includes a plan for delivering a product increment and achieving the Sprint Goal. Often, teams will maintain their plan in the form of tasks to be completed, for example.

How is your team building and maintaining their own Sprint plan, against which progress might then be gauged?

Vishal it’s a great question and I’ve had many occasions where teams don’t see the benefit of the daily Scrum which is understandable if it doesn’t add any value for them. When it doesn’t it naturally falls into a status/check-in/report meeting.

There’s a great video by the great and passionate James ‘Cope’ Coplien (https://youtu.be/LYsl19xEvzMhttps://youtu.be/LYsl19xEvzM) where he asks what the daily Scrum is for. In summary it’s to check and replan the work. The reason for the check and replan is the dev team is operating at high risk discovering things as they go. What they discover will affect the plan in the same way that any adventure goes.

With this in mind think I’ve found it helpful to have three things at hand:

1. Team Code of Coduct: the rules they run by
2. The overall objective of the work for the customer
3. The sprint goal for the sprint

It’s worth reminding the team that it’s up to them to be successful. If they feel that they don’t have much to say then great it’ll be super fast. If they want to express anything it’s a great time to do it. If your the SM your job is make sure the team can do it - the team itself needs to decide for it to happen.

Vishal, when you have a "Working Group" that are separately working on disparate items in silos, it is quite difficult to help them understand the benefit of a Daily Scrum, sharing information, and collaboratively developing a game plan for that day.

Timothy, all agreed. But everyone here is telling what can be done.. But not how?? 

Even though we are willing to work in collaborative environment , we just can't .. because we don't know how .

From developer's perspective - If he has been assigned a story to work on, he gets so much engrossed in that story, challenges he is facing while working on that story ...Apart from this, he hardly has any information of stories others are working on (apart from what ultimate output is expected).. so when we expect collaboration from him (or for that matter any other development team member), what exactly we mean ?   

In simple words, what is the alternate way than to work in silios ??  Pair Programming ?  Our developers do not like it.. what is next ?  What is the other way than to work in silos ??..  

Continue ...

Often, teams will maintain their plan in the form of tasks to be completed, for example.

How is your team building and maintaining their own Sprint plan, against which progress might then be gauged?

Yes.  In the form of tasks to be completed.

Make sure that the group creates a Sprint Goal.  At each Stand Up after everyone has said "I'm still working on the same story" ask if anyone feels the Sprint Goal is still achievable. 

Our sprint goal is made up of one or two high priority items. Only developers working on those items can answer this question. What can be our sprint goal in below case? If you ask me- "Improve user experience" can be our sprint goal. But will this help as a "GOAL" ?

1. Giving user functionality to search branches by regions

2. Giving user functionality to search articles by tags

3. Automation testing 

4. Create "Useful Links" section for search

@Vishal

I'm going to start with this statement you made

From developer's perspective - If he has been assigned a story to work on, he gets so much engrossed in that story,

Who is assigning these story?  Why not let people work on any story and take any task associated to that story if they have the skills to do so?  I have found that taking that approach actually helps break down silos and encourage collaboration. It is a bit strange to the team at first but as people start doing it, they become more comfortable with it.  Your team will most likely still have Subject Matter Experts (read Silo Matter Experts) and they can help to impart knowledge on the different subject matter across the team. 

What can be our sprint goal in below case? 

I would suggest something that addresses the actual work. Your goal is very vague and could be satisfied by completing any one of the first 2 stories.  Why not something like "Improve users access to information by increasing search capabilities and providing directory of useful links while improving the ability to release a quality product."  Cover all 4 stories which in turn makes every story necessary in order to complete the Sprint Goal.  If anyone of the stories seems in jeopardy, then the goal is in jeopardy.

Why not something like "Improve users access to information by increasing search capabilities and providing directory of useful links while improving the ability to release a quality product."  Cover all 4 stories which in turn makes every story necessary in order to complete the Sprint Goal. 

Very very useful. Thanks for this.

Who is assigning these story? 

Development team chooses who will work on the story. There is no individual who does the assignment.

Why not let people work on any story and take any task associated to that story if they have the skills to do so?

It's not just about skills. It's about complexity and knowledge. If particular developer has worked on story A part 1 in sprint 1 then in sprint 2 , part 2 of that story is taken by that particular developer only because he can code quickly as he has done part 1. If any other developer takes it , he will spend lot of time in analysis and there is a chance that the work will not get completed in a sprint.

If particular developer has worked on story A part 1 in sprint 1 then in sprint 2 , part 2 of that story is taken by that particular developer only because he can code quickly as he has done part 1. If any other developer takes it , he will spend lot of time in analysis and there is a chance that the work will not get completed in a sprint.

Something that just jumped out at me after reading the above.   I'm curious if your team has discussed ways to ensure that items continue to progress, regardless of Development Team member availability?

To put another way, it is critical that the items forecast in a sprint are not impeded due to the inability of a certain individual to work on it (i.e. - illness, personal reasons).   

The health of both a team and an organization are closely tied to their ability to keep work moving through their process workflow.   It is not a desirable option to accept a situation where work simply stops because the one working on it is out sick, for example.

I can very much relate to it. I know, in ideal world, we could split a user story between multiple DEVs, but it is just not applicable in our project. A user story is often a complex beast, it is just not feasible to split it into smaller sub-tasks and share it among DEVs. A single DEV usually takes the entire sprint for 1 user story, so everytime in daily scrum, they say the same thing 'Working on story X'.

We don't have clear sprint goals either, so it isn't really a customer-facing product, it is a complex solution, we don't deliver features to the end customers every sprint, it often takes couple of months before we release something which is visible to the users.

I would love to define sprint goals, but as each DEV is working alone on his user story for the length of sprint, sprint goal would be a combined definition of multiple user stories.

It may appear that we are not collabrating enough, but we collabrate during the sprint by doing code reviews, design discussions etc.

In such a situation, would you say that we are not doing proper scrum? If not, how could we evolve to true Scrum?

It may appear that we are not collabrating enough, but we collabrate during the sprint by doing code reviews, design discussions etc.

How would the team choose to break their work down, so they can limit work in progress and focus on completing each piece jointly? Do they recognize a need to do so, and to deliver early and often?

...it often takes couple of months before we release something which is visible to the users.

Ever notice the statement in the Scrum Guide where each Sprint delivers a potentially releasable increment? There are many reasons that something may not be releasable. So as I see this, you are doing things the right way.

...sprint goal would be a combined definition of multiple user stories.

A Sprint Goal should be defined based on combined definition of multiple user stories.  If you are trying to do it based on 1 story, why even bother pulling more than 1 into the Sprint Backlog?  The Sprint Goal is a basic definition of what must be done in order to build that potentially releasable increment. Craft it so that the work being done on multiple stories is reflected in the achievement of the Goal. 

In such a situation, would you say that we are not doing proper scrum? If not, how could we evolve to true Scrum?

This would be a trick question if on an exam.  Based on the situation you have described it is not possible for anyone outside of your organization to say if you are "doing proper scrum".  For this part, some of us would say you are not doing anything wrong while others of us would say there are things you should/could do differently.  Truth is that if you are honoring the Scrum Guide you are doing Scrum.  Procedural implementation is entirely up to your organization. Most of what you describe is procedural. None of us on the outside can say if those are right for your organization. "How do you evolve to true Scrum?"  Read the Scrum Guide often, read the posts in this forum, find multiple sources of information how Scrum has been implemented in various situations. Use these as information not definitive guides.  Honor the Scrum Guide as you define your processes. Evolve incrementally. 

Thanks for sharing your perspective. 

We often release something at the end of the sprint, but it is often not visible to the end users. Because mostly, we are working on building blocks which are needed for a large customer impacting initiative.

So, the release happen each sprint, but not visible to the customers. I'll experiment with defining sprint goals based on a combination of user stories.

Why we pull multiple user stories in Sprint backlog?

Because, a DEV usually owns the user stories for the entire length of the sprint. So, if we pull only 1 story, we don't use the capacity of other DEVs. So, we need to pull in more work;

Thanks for your inputs, it would have been nice if some of our team members/seniors had experience of working in real Agile teams, may be they could throw in some ideas on how to divide work in a better way and promote collabration. Unfortunately, none of us has such an experience.

but it is often not visible to the end users

Stakeholders and end-users are not always the same thing. If you cannot define to whom you are delivering value (by delivering increments of your product), and certainly if it's so vague that sometimes you can't deliver for weeks or even months, you have a long and unwieldy feedback loop and run a high risk of losing opportunities to inspect and adapt.

I'll experiment with defining sprint goals based on a combination of user stories.

I would like to nuance this. Of course it goes hand in hand, and you should have a sprint goal that you can work on with stories that are Ready. But if you're just putting all stories you want to do in one sentence and making that your sprint goal, you may as well simply have every sprint goal in every sprint be "finish all chosen stories". In my opinion it's putting the cart before the horse. Instead, start with an ambitious-yet-realistic Sprint Goal, and then assemble your Sprint Backlog in a way that can actually meet that Sprint Goal. This is hard, because it requires smaller stories that are easier to get Done independently, so that they are easier to (re)order, plan and forecast. Which leads into the next bit.

Because, a DEV usually owns the user stories for the entire length of the sprint.

If your user stories are usually that big, then what happens if a dev is done a day earlier than expected? Or a day later? As a developer, I would find it difficult and stressful to forecast sprint capacity with stories that big. And as a product owner, I would have a hard time ordering stories and re-ordering them based on a changing world, and maintaining Product Backlog transparency.

may be they could throw in some ideas on how to divide work in a better way and promote collabration. Unfortunately, none of us has such an experience.

What do your developers and product owner think of the situation; do they feel like they're missing the boat in terms of value delivery? Do they share your feeling that this is a hurdle? If so, then this could be considered a problem with the cross-functionality in your team, maybe even an impediment. So, then, what possibilities has your team considered to create or import this experience?

"We often release something at the end of the sprint, but it is often not visible to the end users"

What does Scrum Guide say about intended audience of the release?

" A single DEV usually takes the entire sprint for 1 user story, so everytime in daily scrum, they say the same thing 'Working on story X'." - why not say something more? If on average everyone has a minute, then he could also foster team communication by saying: "I finished implementing base classes for X, today I plan to create UI for them. No impediments" - see, so much more info, even though still one story / PBI.

If your user stories are usually that big, then what happens if a dev is done a day earlier than expected? Or a day later? As a developer, I would find it difficult and stressful to forecast sprint capacity with stories that big. And as a product owner, I would have a hard time ordering stories and re-ordering them based on a changing world, and maintaining Product Backlog transparency.

If a DEV is done with his story, he usually pulls in something from the backlog. If possible, he can try and help other members to finish their story (not the case too often).

What do your developers and product owner think of the situation; do they feel like they're missing the boat in terms of value delivery? Do they share your feeling that this is a hurdle? If so, then this could be considered a problem with the cross-functionality in your team, maybe even an impediment. So, then, what possibilities has your team considered to create or import this experience?

Fellow developers and Product owner are not really bothered about it. Our team is mostly predictable in terms of deliveries, so there is no real concern on that side.

It again comes down to the problem that it takes us months to release something which is usable/visible to end users. It is a backend application for financial processing, we can't really have feedback from external stakeholders every 2 weeks, as for most of time, we are working on "building blocks' for the final application.

Some people suggested that our project is more suitable for Kanban, but I still like Scrum, as it provides us biweekly check points to monitor our priorities, opportunity to retrospect, it has improved our predictability, as we focus on splitting the small in smaller user stories which can be finished in less than 1 sprint.

Vishal- it sounds frustrating that your team doesn't go into much detail on their progress during your daily Stand-up. Our team at Digital Maelstrom follows a basic template for our Stand-ups: each person explains what we worked on yesterday, what we will be working on today, and any values that may be preventing each individual from completing their stories. Because our team is relatively small (only six team members) each person talks for about two-three minutes each time. We have opportunities to ask our teammates questions about a specific issue/story during our speaking time, or wait until the end of the meeting to discuss the project more in-depth. Perhaps you team members can explain the specific tasks they completed within a story each time they speak during the Stand-up. I hope this helps.

If on average everyone has a minute, then he could also foster team communication by saying: "I finished implementing base classes for X, today I plan to create UI for them. No impediments" - see, so much more info, even though still one story / PBI.

Thanks. We have started this practice.

Perhaps you team members can explain the specific tasks they completed within a story each time they speak during the Stand-up. I hope this helps.

Indeed. We have started this practice. Thanks.