story assignment during planning

I guess priority is only for PBI, once they are pulled into Sprint backlogs all are equally prioritized. There should not be any sprint level priority.

I am skeptical about sprint level prioritization. This is as good as interfering into development teams work (not advisable for a good scrum practice.

Interference into developers work is acceptable unless there is a REAL priority item that needs to be replaced by an existing item in current sprint, but ultimately that should come from product backlog (post refinement etc).

> I am skeptical about sprint level prioritization. This is as good as interfering into
> development teams work (not advisable for a good scrum practice.

This depends upon who is doing the prioritization. A Development Team can choose to prioritize certain items on their own Sprint Backlog if they believe it will help them to achieve the Sprint Goal. However, no other party has the right or responsibility to set these priorities. Any attempt to do so could indeed be tantamount to "interference".

> I guess priority is only for PBI, once they are pulled into Sprint backlogs all are
> equally prioritized. There should not be any sprint level priority.

The Development Team can establish sprint level priorities if they believe it helps them to achieve the Sprint Goal.

Look at it this way. You know that a Sprint Backlog is never frozen, and that a team can revise it as needed during a sprint in order to meet the Sprint Goal. Replanning doesn't stop and Sprint Backlog items can be added or removed if necessary. By definition, if a Development Team adds or removes items from a Sprint Backlog then they are changing sprint priorities. Deciding which to action first, but without adding or removing any from the backlog, could be a comparatively trivial case of replanning to meet the Goal.

Thanks Ian, Agree. Developers can have their own prioritization details (internally).

Am I right saying that it should not be exposed on task boards or scrum tools (that makes it visible to PO or Stakeholders ?)
Or can that be made visible as long as priority of Sprint can be nailed down to PBlog?

As a general rule information should be exposed and radiated across the organization, rather than censored. This provides an opportunity for stakeholders to spot problems and/or offer solutions via the Scrum Master.

If there is a danger of parties interfering with a Development Team's work, on the basis of information the team provides, then that is a impediment which the Scrum Master should rectify.

+1 to Ian's answers. Thanks for your contributions to this board, Ian!

Apologies for bringing life back to this thread... 

...however, if I understand correctly, the SPRINT priority is determined by the development team. Product cannot interfere with the team prioritisation of the work taken within a sprint. Is that correct? 

...however, if I understand correctly, the SPRINT priority is determined by the development team. Product cannot interfere with the team prioritisation of the work taken within a sprint. Is that correct? 

The Scrum Guide changed a few months ago to remove Development Team in favor of the Developers of the Scrum Team. Nonetheless, the Developers are accountable for the Sprint Backlog and may self-manage their work in any way they choose. So yes they may determine the order of what gets worked on, as long as there is a focus and commitment to meet the Sprint Goal. The entire Scrum Team, including the Product Owner, establish the Sprint Goal by the end of Sprint Planning.

Product cannot interfere with the team prioritisation of the work taken within a sprint. Is that correct? 

If there is a wish to interfere, ask why. Finished work can be delivered at any time during a Sprint, and perhaps there is a need for collaboration so the release of value will be maximized. What were the intentions in Sprint Planning?

Our Scrum implementation is extremely micro-managed by Product. There are even power points (aside from the backlog) with the upcoming sprints roughly laid out for each team. We are basically Feature Driven. We estimate in refinements so that Product can then decide what the priority is. 

It's a long sad story but unfortunately I don't think it's a unique one. I am trying to deep dive a bit into Scrum now to see if I can find small improvements we can all agree on. I do not have the luxury to compare Scrums from past experiences in other companies. 

What I do not understand is the idea of a Sprint Goal when we are working on features spread all across the different aspects of the product. Sprint Goals are not meant to be a list of features but I gave up a couple of months ago trying to invent a meaningful goal for each sprint. 

Can you give me an example of what user stories an ideal sprint could contain and how that would translate into a goal?  

An example sprint for us would be something like:

* Add search field to PRODUCT ASPECT A

* Add filter to PRODUCT ASPECT B

* Add column to search results in PRODUCT ASPECT A

* Add search field to PRODUCT ASPECT A

* Add column to search results in PRODUCT ASPECT C

How would you define a goal for such a list of user stories?

I see many new Scrum teams struggle to come up with a Sprint Goal because the Product Owner hasn't ordered the Product Backlog by a cohesive set of features. That's one reason why we say the Product Backlog is ordered, not prioritized. A second common reason why there are struggles with the Sprint Goal is that the team is not working on one Product.

The Sprint Goal provides a focus for the Developers, provides guidance, and can be a motivator. Otherwise Developers may start to feel like a hamster on a wheel just churning out work.

The Sprint Goal should be focused on an outcome, such as increasing customer satisfaction. The Product Owner is the person accountable for maximizing ROI from the money spent every Sprint, and the Sprint Goal should help answer "why carry out this Sprint?". "If it was our money being spent, what value would we want to achieve by the end of the Sprint?". Your Sprint Goal may even be related to proving out a hypothesis or an experiment. 

For your example, the Scrum Team (yes the entire Scrum Team crafts the Sprint Goal in Sprint Planning) should ask themselves what objective would be fulfilled by adding search filters. Perhaps your Sprint Goal would be something like "Increase accuracy of search results by 20%" or "Reduce phone calls to customer reps by expanding self-service search tools".

Here's an example I use. As a Product Owner, you've seen an increase in mobile web usage by 40% over the past 6 months, and your customers have been asking for more mobile-friendly payment tools. You've ordered the Product Backlog with the following PBIs:

• Apple Pay
• PayPal
• Mastercard
• Square
• Amazon Pay
• Bitcoin

In Sprint Planning the Developers discussed the PBIs and decided to select Apple Pay and PayPal, based on their capacity, velocity, and some other factors.

The Scrum Team came up with the following Sprint Goal: "Increase payment completion rates for mobile-web customers".

Those look more like tasks than user stories. Where's the room for negotiation and creativity amongst team members, which might inspire them to have a shared goal at all?

@Chris Belknap gives some great advice and said it much better than I could.  

You asked for a suggestion of a Sprint Goal for that list of items.  My first impression was "Introduce search improvements for multiple ASPECTS" because that would also allow for changes in the Sprint Backlog if one of those stories proved to be unable to be finished during the Sprint and it was swapped out for another story on a different ASPECT.  

Second idea was "Increase search capabilities for ASPECT A and C" because the adding of a filter to ASPECT B doesn't fit with the other two.  And since there were similar work being done for 2 ASPECTS I would make that the focus of the Sprint.  Remember, not all work contained in the Sprint Backlog has to support the Sprint Goal.  The Sprint Goal is to identify the main reason(s) for undertaking the body of work.  But that doesn't mean the team can't slip in a litlle extra work. 

@Chris, @Daniel -

that is very helpful. Thank you. We do try to isolate the main stories in a sprint to identify a goal but it usually ends up being a list of stories. However, if every sprint is very similar then the goal does not change from sprint to sprint. 

Unfortunately, I feel like a hamster on a wheel just churning out work and I believe this is the general feeling of the team.

@Ian - Interesting point. If my user story examples appear to be tasks then what would the user story be? We iterate on 2 week sprints and these stories fit that time frame. Also, there is very little negotiation and zero creativity opportunities. Although trying to come up with original sprint goals can be a creative challenge :)

If my user story examples appear to be tasks then what would the user story be?

A user story is a placeholder for a conversation about a potential requirement. It sounds as though someone might wish to search within multiple products, and then perhaps expects the results to be manipulated in some way. What the desired outcome is I have no idea.

@seamus - Here is a short exercise you can run that shows what outcomes to expect when a small team is given a simple vision vs a set of requirements:

• Summer Meadows: https://blog.crisp.se/2009/02/18/davidbarnholdt/1234986060000

Hello Chris and others, thank you for greeting me in this forum. Thanks for the short exercise. Will proceed there shortly.

Thanks @Chris - that's a very interesting exercise.

Unfortunately we are not given visions. We are handed "tasks" to be implemented.

if every sprint is very similar then the goal does not change from sprint to sprint. 

There isn't a requirement that the Sprint Goal must be different from sprint to sprint.   For example, you could string together a number of sprints with the same Sprint Goal "Improve customer experience", but with different items in each sprint to accomplish that goal.



I have had some success working with teams to start their Sprint Goal statements with an action verb, such as Improve, Reduce, Eliminate, etc.   Also, see if the team can identify the business value in the Sprint Goal, as this will help them focus on the 'what', and not the 'how'.

   

@Chris - what does PSL mean in the context of the exercise? Is it Problem Statement Language?

@Timothy - this just might be one of those "AHA!" moments for me!! Thank you very much. The simple idea of being able to use the same goal across sprints is not just practical but also resonate with product on a different level.

@seamus - I don't think PSL is relevant to the exercise, it is some type of course the author of the blog offered at the time.

@timothy - Thank you for the tip on starting a Sprint Goal with a verb and tieing the Sprint Goal to business value, solid advice.

My feeling on stringing together the same Sprint Goal over many Sprints is that it might be better to use a Product Goal for that, and to see if you can come up with unique Sprint Goals as stepping stones towards a measurable Product Goal.

"Start with a verb" is a great idea.  I used it with one team that consistently struggled with defining any kind of goal.  Phrasing the goals in that manner became a battle cry for them.  It was really funny how the "it doesn't start with a verb" comment would lead to some creative, and sometimes funny, goals.  But it did the trick to help them focus on crafting goals that were understandable and attainable.  I had completely forgotten about that until I read @mothy Baffa's post. 

@Chris - what does PSL mean in the context of the exercise? Is it Problem Statement Language?

from the article

The Problem Solving Leadership class ...