Priotirized Spring Backlog

The ordering of work in a Sprint Backlog is entirely up to the Development Team, because they wholly own it. It is their plan and forecast of work for meeting the Sprint Goal, and they can revise that plan as needed.

The issue you describe is not so much one of prioritization but rather one of limiting work in progress. The team should be able to express a joint focus on each backlog item so it can be completed quickly and Sprint control thereby evidenced. There may be a natural ordering to this work which avoids technical dependencies in implementation, but this is not necessarily the same as the order found in the Product Backlog.

Generally speaking, a team commits to meeting a Sprint Goal where an end-of-Sprint increment is integrated and made available for release, and not to working on Sprint Backlog items in any particular order.

Thanks for your answer, Ian. In the past I've seen/defined Sprint Goals like "Please finish these 5 User Stories". Sprint goals in practice are still a mystery to me. I'll read your article :-) 

Any ideas if and how a Scrum Master should investigate if he sees that the team is starting many user stories in parallel?

 

As a Scrum Master, make your observations known, and help guide the entire Scrum Team to better ways of working.

In regards to your scenario, what is the impact of the team working on many items in parallel?   Does the PO have any issue with items finishing late in the sprint?   If the Dev Team is meeting their forecast each sprint, do the PO or Dev Team perceive any issues around work completion?

You mentioned that the burndown chart looks ugly - are there suggestions for making the burndown chart "burn" better?   Does it need to burn better?   Who is the audience for the burndown chart, and what is their feedback?

As Ian mentioned, your situation is more of a WIP issue around flow than a Scrum issue.   While there may be benefits found in limiting WIP, or pairing/mobbing around PBI's, it may be difficult to suggest a change in behavior (experiment) if the team is meeting their forecast each sprint and the PO/customers are happy about the end product.

As a Scrum Master, make your observations known, and help guide the entire Scrum Team to better ways of working.

 Is the retrospective the right meeting to communicate these observations? As a SM I would take an active role and step out of the facilitator role?

In regards to your scenario, what is the impact of the team working on many items in parallel?   Does the PO have any issue with items finishing late in the sprint?   If the Dev Team is meeting their forecast each sprint, do the PO or Dev Team perceive any issues around work completion?

Working on many items in parallel raises risk of delivering nothing done at the end of the sprint. As I learned the PO can't express business priorities by ordering the Sprint Backlog. A PO has the express the priorities by defining a proper Sprint Goal. As a PO I wouldn't have any issues when items finish late in the sprint. Maybe the Dev Team has an issue building the increment depending on the source code branching strategy. This can be hell.

 You mentioned that the burndown chart looks ugly - are there suggestions for making the burndown chart "burn" better?   Does it need to burn better?   Who is the audience for the burndown chart, and what is their feedback?

The burndown chart should be a tool for the Dev Team to show progress. Sometimes I struggle if a drawing a burndown is just waste. What do you think?

As Ian mentioned, your situation is more of a WIP issue around flow than a Scrum issue.   While there may be benefits found in limiting WIP, or pairing/mobbing around PBI's, it may be difficult to suggest a change in behavior (experiment) if the team is meeting their forecast each sprint and the PO/customers are happy about the end product.

Yes, thanks. Maybe you have some input how the to do foster continuous improvement when the Scrum Team is happy meeting the Sprint Goals regularly.  

Working on different PBIs in parallell can make inspecting and adapting a lot harder. The issue with an "ugly" burndown isn't that it's ugly - it's that you can't tell whether you're on course to meet the Sprint Goal - at least not from the Burndown Chart. But in the end, that's what it's for. It's a tool to make the progress towards the Sprint Goal visible.

Just like multiprocessor scheduling is a lot harder than scheduling on a single processor, inspecting & adapting when the team works on multiple PBIs at one is harder than when the whole team swarms on one PBI, then the next, and so forth.

You may want to take a look at this: https://sites.google.com/a/scrumplop.org/published-patterns/product-org…