Scrum question

to 1) your first part of your description is correct, a cross-functional team means that members cover more domains (at least two). in you example the person with a good background of IT-Analyst , must be able also to help others in their current tasks if needed, for example the "analyst" could volunteerly pair programming with a developper or help the "tester" to define smart test cases. The team members learn from each other. A database expert is very welcome but he/she should be able/wish to take/learn other sprint tasks.

to 2) I think such a PO is an impediment, which Scrum master should solve it as soon as possible. One of the solution could be finding a new PO who has time and know how to support the Dev. Team by crtical decisions. I think a senior domain expert with previous PO experience from similar products comming from Business department is a better candiate than a someone form existing Dev. team. A PO is a value Optimizer and they should know exactly who are the stakeholder (of future product) and what they need, They must know also market, competitor etc. to make a right decision. He/ She has typically a manager position otherweis would probably have difficulty to negogiate with other managers and stakeholders.

Mehdi

1. The term "cross-functional team" can be used in two senses. The first sense is the one you refer to: the individual team members are cross skilled. This facilitates the efficient actioning of work, as the risk of bottlenecks is reduced. Any team member can go to where the work is and do whatever needs doing when it needs doing.

The second sense of a "cross functional team" - and the one which is referred to in the Scrum Guide - means that a team has "all of the competencies needed to accomplish the work without depending on others not on the team". That definition does not necessarily imply any cross-skilling between team members. It just means that all of the requisite skills needed to achieve the Definition of Done can be found within the team itself. Being able to meet the DoD is important in Scrum, so despite immediate appearances, this isn't a weaker definition.

Ideally, an agile team will be "cross functional" in both senses of the term.

2. The Product Owner determines product value and is responsible for return on investment. The PO may genuinely own the product in some cases, and without a co-operative PO it can be argued that there is no product at all. Unfortunately, a team is no more able to elect a new PO than it can elect a new product.

In the situation you describe, and as Mehdi has explained, it falls to the Scrum Master to deal with the impediment presented by an uncooperative Product Owner. The Scrum Master has a wider duty to organizational stakeholders. As such, the Scrum Master should inform those stakeholders of the concerns, and of the risks presented by inadequate product ownership. The focus should be on the problems caused to date and which are likely to result in the future...not on the failings of the PO as a person. It should then be left to those stakeholders to make the decision whether or not to replace the PO. The Scrum Master would be wise to keep communication channels to the stakeholders open regardless of the outcome.

Hi
Mehdi & Ian Mitchell, thank you very much for detailed & helpful answers!

According to my previous question I want to ask the following:
If the PO is not collaborative, may the Dev. Team members (not a Scrum Master) direct communicate with the stakeholders during the Sprint Planning? Maybe stakeholders have a detailed useful information about PB items, which could help the Dev.Team...

and another little question: may I call the Product Backlog Refinement (grooming) also "Release Planning"?

Thanks a lot
Jeny

> If the PO is not collaborative, may the Dev. Team members (not a Scrum Master)
> direct communicate with the stakeholders during the Sprint Planning? Maybe
> stakeholders have a detailed useful information about PB items, which could help the Dev.Team...

No, because that is circumventing the Product Owner, and undermining the role and its duties. It will compound the problem and not resolve it. In Scrum, the Product Owner must represent the Product to the Development Team. Once product ownership is compromised the product also becomes compromised.

> and another little question: may I call the Product Backlog Refinement (grooming)
> also "Release Planning"?

Neither of these are actual Scrum Events so the terminology isn't rigorously defined. But what are you trying to achieve by conflating the two activities?

I try to answer your second question:

and another little question: may I call the Product Backlog Refinement (grooming) also "Release Planning"?

No. They are different.

PBI- Refinement (grooming): means that Product Owner and Dev.Team meet each other during current sprint and go through the PB Iteams one by one and groom them, e.g. add more detail informations or rephrase the rerquirements to make it more understandble, change its estimated story size , define what is in scope or out of scope, split it if it is too big for a sprint or merge together if they are too small and dependent to each other,...etc. normally it happens for the PBIs on the top of PB list which are next candiates to be pulled by the next sprint(s). In other words such refined PBIs are deemed “Ready” for selection in a Sprint Planning. Refinement usually consumes no more than 10% of the capacity of the Development Team.

Release Planing: I pasted below the removed part of older Scrum Guide version (2009) , It descreibs the Release Planing Meeting, by reading that you understand easily what does it mean Release planing:

Page 6 -Scrum Guide 2009 > RELEASE PLANNING MEETING
The purpose of release planning is to establish a plan and goals that the Scrum Teams and
the rest of the organizations can understand and communicate. Release planning answers
the questions, “How can we turn the vision into a winning product in the best possible way?
How can we meet or exceed the desired customer satisfaction and Return on Investment?” The
release plan establishes the goal of the release, the highest priority Product Backlog, the major
risks, and the overall features and functionality that the release will contain. It also establishes a
probable delivery date and cost that should hold if nothing changes. The organization can then
inspect progress and make changes to this release plan on a Sprint-by-Sprint basis.
Products are built iteratively using Scrum, wherein each Sprint creates an increment of the
product, starting with the most valuable and riskiest. More and more Sprints create additional
increments of the product. Each increment is a potentially shippable slice of the entire product.
When enough increments have been created for the Product to be of value, of use to its investors,
the product is released.
Most organizations already have a release planning process, and in most of these processes
most of the planning is done at the beginning of the release and left unchanged as time passes.
In Scrum release planning, an overall goal and probable outcomes are defined. This release
planning usually requires no more than 15-20% of the time an organization consumed to build
a traditional release plan. However, a Scrum release performs just-in-time planning every Sprint
Review and Sprint Planning meeting, as well as daily just-in-time planning at every Daily Scrum
meeting. Overall, Scrum release efforts probably consume slightly more effort than traditional
release planning efforts.

Release planning requires estimating and prioritizing the Product Backlog for the Release. There
are many techniques for doing so that lie outside the purview of Scrum but are nonetheless
useful when used with it.

I hope that it could help you
Mehdi

One more point: based on Scrum Guide 2013 (Changes).pdf, the word Refined is now the preferred word

3. The Product Backlog is refined rather than groomed. The refined Product Backlog
items are transparent, well enough understood and granular enough to be input for
the Sprint Planning and for selection for the Sprint. Product Backlog items with this
transparency are called “Ready.” Ready and Done are two states that reinforce
transparency.

Thank you for your answers and explanations!
I made a mistake and red every paper about Scrum I got. So now I'm confused about different term and definitions. I try to understand each definition.

Could you please give me a definition of "stakeholder" in general?
It is clear, that the PB is only the job of PO and "the Dev. Team is't allowed to act on what anyone else says."
Few pages further I red about the Sprint Planning:
"The Dev. Team may also invite other people to attend in order to provide technical or domain advice."
Are these advisors also called "stakeholder"?

"The Dev. Team may also invite other people to attend in order to provide technical or domain advice."
Are these advisors also called "stakeholder"?

Not necessarly.

1) Short :Stakeholder of a product is everyone with an interest (or "stake") in what the product does.

2) Long ; assume that we are a development Team which implements a product (solution) a web-application for booking hotel rooms through internet. The end users , the normal people who use our web-application to book their rooms , are stakeholder for our the product , but also hotel managers for example who get specials account to register and update the information of their own hotels in the database, are also stakeholder for the product. These two examples were examples of external stakeholders.
a product has also internal stakeholders for example: IT Analyst , Developper, Product owner, release manage , operator , test team,... they are internal stakeholder of the product.

The stakeholders have completely different views and requirement. End user wish a user friendly GUI with Help textes but an operator who will be the responsible for running product in live system may be needs good document where the steps of patch installation are exactly described.

as you see the different groups and roles couldhave differentrequirements , It is a very important to identify all relevant stakeholder and consider their requirements on the product, to solve if there are conflicts among them.If we forget an important stakeholder , later could it cause huge extra cost to correct it or even we risk the product not be accepted at all. This analyisis normally happens during requirement analysis activities, In scrum the Product owner is responsible for that and involve all relevant stakeholders and consider their needs.

please be aware also that to identify all relevant stakeholder is not a easy task and needs domain know how , brainstörming, interviewing the experts. stakeholders are not always persons, they could be also impersonal such as ; standards , laws, , .... they have probably requirements for our product. for example in our hotel room booking application prabably international IT data security rules defines standards for handling of personal data of users,.... which must be fullfilled. Or an anti discriminiation law prescribes that for blind user our web-application must support offer read text feature .. etc.
Sometimes even special group of ilegal user "Hackers" could be considrate as stakeholders , in this odd case , the team must know what are typical ways of cyberattacks and these must be taken into consideration in design to prevent them. for example preventing a SQL-Injection attack on fileld of Graphical User Interface.

thank you for great explanation!