20
If the team is truly self-organizing, then the members would recognize that they have an issue that needs outside assistance and would, among themselves, find a way to resolve it. One option would be seeking someone else, either inside or outside the organization, who is a subject matter expert who can provide an expert decision. Another option would be to ...
18
Mark, you are absolutely correct that the PO has final say on the backlog and execution is owned by the development team. This doesn't mean that the development team doesn't have input or say. They should absolutely advocate for things they think are important. However, the Scrum Guide is very clear that:
"The Product Owner is the sole person ...
14
There is no canonical answer to this question, although as a rule of thumb, it would be better for the PO to be from the client side, not the contractor side.
The Scrum Guide says this about the PO role:
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
Clearly expressing Product Backlog ...
14
And I'm going to take the middle ground between Bogdan and Thomas...
Whichever side has the more competent PO.
Bogdan already listed the responsibilities of a PO. To (over)simplify it in a single sentence, however, it would be:
The purpose of the PO is to act as a link between the customers and the Development Team.
As such, the PO is really the only role ...
11
In Scrum, "the team" is ultimately deciding how to implement stuff (within constraints that may be given by the organization.)
Of course, this depends on the team being able to work together and come to a consensus. If one half insists that code must be written in C while the other half doesn't accept anything but Java you don't have a coherent ...
8
Treat it like you do with vacation days
If someone needs to learn some things, and they are not working on stories in the sprint, then it's like if they were on a sick leave or in a vacation. When that happens, you decrease the capacity of the team when doing your sprint planning. That means you take fewer stories in the sprint because you have less people ...
7
I'm going to disagree totally with Bogdan's answer. I believe that, in most cases, it's better for the developing organization to supply the Product Owner. There may be cases where it does work out, but I'm hesitant.
The first thing to consider is why you are contracting with a software company instead of building the software yourself, internally. It's most ...
7
Self organizing is not an automatic statement about a SCRUM team. You don't get it simply by using SCRUM. The goal is to get to that point, and SCRUM's advocates claim that it helps you get there.
The self organizing concept is tempered by a key line from the SCRUM guide
Individual Development Team members may have specialized skills and areas of focus, ...
6
Work and pressure is a spectrum
If you do something like Waterfall it doesn't mean that you work at full capacity, and if you do something like Scrum it doesn't mean the team can slack off. If you do Waterfall it doesn't mean you are under pressure to do the work, but if you do Scrum you can just relax and do things when you eventually feel like it. These ...
6
The chance that a team is evenly split on a decision between (options) and even after discussion becomes deadlocked exists but it is extremely small.
There is a higher chance that two people in the team have opposing opinions and adamantly hold to those opinions. In that case, the majority could push their idea through, but that will probably have the same ...
5
The PO should have the final say over priorities and what items on the backlog get put into a sprint. In Scrum there is no PM. It doesn't really matter what you call the person performing the PO role but it is obviously important that there is a clear set of decisions.
The only significance of prioritisation is that it helps the team to decide what to ...
5
You should not consider development and testing as sequential activities within the sprint, or the thing you describe happens. Development and testing should happen together as a collaboration between devs and testers. It requires a change in the way you work. See more details here: What does a QA team do during the development phase of a sprint in Agile ...
4
I think that your second image is a template that you should use to plan out your Sprints. Where did you get the image?
You do a longer release planning with Scrum by:
organizing your backlog with proper priorities for the items;
do a rough estimate of the backlog items;
then using your team velocity and known duration of a sprint, try to figure out how ...
4
Yes. A common rule of thumb for a two-week sprint is that most backlog items should take 2 - 3 days to complete including QA, deployment, etc. This is just wisdom for experienced teams though, not a hard-and-fast rule. It will also take time to get there. If the team is used to a backlog item taking a full 2 weeks to complete, they aren't going to jump to 2 ...
4
TL;DR: Once a story is completed, the team needs feedback on it. This can be done as stories are completed, or the team can receive feedback during the Review Meeting. The sooner, the better.
During Sprint Planning, the team decides what user stories and product backlog items to pull into the sprint. They choose on what they will be working on from the items ...
3
I encourage the teams I work with to show their development work to the Product Owner throughout the sprint. This makes the need to have a Product Owner review at the end less important.
It also helps to reduce the frequency of requirement misunderstandings.
3
In Scrum, the Sprint Planning occurs at the start of every Sprint. In most implementations of Scaled Scrum, the Sprint Planning is synchronized among the teams and often has a shared component where the teams align their plans for the upcoming Sprint. In SAFe, this activity is represented by Iteration Planning on the team level.
SAFe's Innovation and ...
3
I am in the same situation, I am a PO on the client-side. To me, that is the only option because most times the contractors are after their selfish interest. The PO has to defend the customer and business objectives in delivering business value. The PO needs to be able to make strategic decisions in view of the overarching business strategy. The contractors ...
3
Client side. The PO needs to be able to identify the business priorities, provide subject-matter expertise and justify his or her decisions to the client organisation. Most software probably requires organisational or procedural changes at the client so it's also an advantage if the PO is in a position to make such changes happen. Finally, it's to both ...
3
I am not aware of a process that explicitly discourages developers to pick their tasks. Instead, most agile frameworks encourage the use of self-organising teams.
One aspect of being self-organising is that the team will decide how tasks are distributed amongst the team members.
It would certainly be legitimate for a team to try a random or pseudo-random ...
3
You ask:
Is there a process that promotes the group to assign tasks to individual developers. The tasks should be assigned as part of a group decision and as part of what comes next.
What you need to do is to explain to the team (those doing the picking) what you are aiming at. This may then encourage them to divide up the task as you expect.
Once they ...
2
Everyone has deadlines to meet. Scrum helps teams to meet deadlines by making sure they align themselves to priorities set by a Product Owner and by working in short iterations. The expectation is that iterations are short enough that teams can have the best chance of meeting the dates they forecast for each set of deliverables. Scrum doesn't of course stop ...
2
Actually, there's another strategy: "cooperating de facto 'product owners' on both sides!"
On the customer side, this person is tasked with directly representing the business interests of the company as they relate to this software. This person can most easily put himself or herself into the "proxy position" of representing the actual ...
2
I think the key difference between Agile/ Scrum and the traditional waterfall way is: Time is "Fixed". It means Scrum teams work at a sustainable pace to deliver the highest priorities first. So, we minimize the situation when the team rushing time to deliver a "fixed" scope.
But it doesn't mean Scrum teams have no sense of urgency. They ...
2
There are always questions that can't be answered at the start of a project. You begin with incomplete information and learn more as you go on. This is a well-known principle called the Cone of Uncertainty and it means that decisions taken at the start of a project have to be made based on information that may prove to be incomplete or inaccurate. This is ...
2
Agile is not a methodology, much less a project management methodology. Organisational agility is all about having a organisation that is responsive to change with empowered teams. The Agile Manifesto for Software Development is a set of ideas about how to do software development work, and various frameworks and management approaches have been devised that ...
2
In the one governmental scrum project I worked in, the government agency used an external IT consultant as Product Owner.
This ensures that the product owner has no split loyalties while having the necessary expertise. On the negative side, the product owner needs significant ramp up time to understand the requirements, and the possibility of disagreement ...
2
There are a few different ways to approach this problem.
From a Scrum perspective, your Development Team does not have sub-teams. You may have specialists, such as people who specialize in testing, but the whole team should be involved. Rather than putting the QA specialists in a position where they must test everything at the end of the Sprint, the whole ...
2
Agile is about self-organizing teams. The team is the one that can figure out the best way of doing the work, and usually, you end up with some kind of pull system. People take work, they are not assigned work.
If the team decided it's a good idea to encourage everyone to take tasks that they are not familiar with, then that's one thing. If you want a ...
1
A great option where cost risk is shared and where scope is largely defined is a cost plus fixed fee. In this case, both the seller and buyer are at risk for cost increases and therefore motivated to do what they can to keep costs from climbing, unlike a T&M where the seller is motivated to maximize charges. This type of contract also avoids loading up ...
Only top voted, non community-wiki answers of a minimum length are eligible
