As a user I want to sort all tasks in Sprint Detail by Point Person in a flat view of the tasks, to easily see all tasks for each person grouped together.

Edit Subject

I would have agreed with this as of a year ago.

However, because of this limitation (as well as some enlightening conversations that occurred when I took another ScrumMaster training course) I started to experiment with running the sprint with a focus on backlog items instead of on individuals - this means we go to a backlog item and we discuss the overall status of the item and update hours for everyone who has tasks associated with that item. This has the advantage of helping the team to focus their efforts on completing whole backlog items instead of rushing through all their assigned items and leaving bits undone. Finally, at the end of the sprint we go through and ask the other two "Scrum" questions - "what are you doing next?" (and then we assign tasks for the next day) and "is anything impeding you?"

While I don't necessarily disagree with this feature request, I'm sharing my experience with you in the hopes that the different perspective might be useful to you.

What you suggest is essentially the mode of working we have switched to, using the we based scrum view instead. I agree that is is better, though not everyone on our teams is convinced!

Having tried for a couple of sprints working though backlog items rather than by person, we have in general found it makes the scrum much less efficient. People end up speaking multiple times, which can take longer. Sometimes tasks get missed if someone has (usually for some sensible reason) done some work on one of the currently less important backlog items . This may say more about the way we are working through the tasks rather than the tool though.

That said, what we do now is use the filters to display just a single user's tasks at a time, so the lack of a flat view is not so serious. It simply requires a few more clicks to change between people.

Evelyn, It would help me to understand and apply the approach if I knew the answers to the following.
- how many people are in your team?
- how long does going through the overall task status take?
- how long does going through the three standard questions take?
- how long is the scrum in total?

Hi Matthew,

Thanks for following up - I love that you're clearly thinking about process and about how to help your team grow!

- My team has 8 people - 3 devs, 2 testers, 1 documentation writer, and one part-time dev and 1 part-time designer (both work partially on another team), and me: the full-time scrummaster.
- Task status is the real variable in our scrum length: if everyone was able to work uninterrupted on their items then it goes quickly (5 min). However, if there were problems then we'll end up talking a little bit more (10 min) - and if it becomes a technical discussion I make sure to ask those involved to continue it after the meeting. So in actuality, our "what is blocking you?" question comes up in two parts: what was blocking you on what you were doing, and then I ask it again about what we anticipate will block us moving forward the next day - the second one usually ends up being more organizational and the first one is more technical.
- The whole meeting is the three standard questions.
- The scrum meeting is *never* more than 15 minutes, and is usually between 8 and 10 minutes. (When I first started this method I struggled to keep it under 15, but as I worked the kinks out the time dropped.)

If your goal is to focus on completely wrapping up the top items before you start on the bottom items (i.e. actually finish PBIs instead of having all your PBIs "in progress") then people will bunch towards the top and several team members will talk about the progress towads finishing that PBI - which in my experience has sped up the scrum.

I believe that the absolute key to my method is that tasks remain "unassigned" until the day the person is actually going to work on it. This has two benefits: 1) most of the time I don't have to worry about missing an item because it's easy to see which items are assigned. 2) It helps to focus team members on getting the highest priority items done. Occasionally we have to work on the lower items, but this is something that the team decides during the scrum meeting and each member commits to getting specific tasks done in the next day - this commitment (to the *team* not to me) is extremely important in the team dynamic and helps to avoid unilateral decisions to go in a different direction.

Hope this helps!