It's impossible to answer your question because "Scrum Master" and "Product Owner" are roles, not job titles. Their job positions may be different and depend on the company.
For example, a Product Owner could be:
A business analyst at your company.
A person from the customer side (i.e. outside your company).
Or even the СЕО of your company (it's not rare ...
It is possible that a developer also acts as a product owner but I don't think that it is recommended. Here are my 2 main reasons:
It may create conflict of interest
It will drag down your output as a developer
PO has to prioritize the backlog (the what part) where as the team decides amount of work that can be delivered in each sprint (the how-much part). ...
Product Owners Are Silent Observers in Daily Stand-Ups
In the quoted description, the word participate has the connotation of "taking an active part." The Product Owner should attend, but should not participate. The daily stand-up is intended as a synchronization and coordination meeting, not a status meeting, and the Product Owner has no active role to ...
Scrum Exposes Technical Debt Through Forecasts & Estimates
As a general rule, technical debt increases the cost of future work on the product. So, even if you don't explicitly keep track of the debt, it will typically show as a drag on metrics such as the team's velocity over time.
Technical debt will probably also impact your team's estimates of ...
My question is, to what extent should the PO describe the requirements of a UI?
To the extent that the designers know what to design and the programmers know what to program. In your example, "as a user I want to see a list of dates so I can..." seems to be a good user story. Who else would know what the purpose of that user interface is and what data the ...
It is worrying that you have no why part to your user stories. This is an important element of the user story format as it allows us to evaluate the stories and to prioritise them. It appears that you are writing technical requirements but partially using the user story format.
I also notice that you focus the stories on the admin, when I suspect the value ...
Business Analyst works with the Product Owner and provides him with valuable insights on the value and importance of the user stories, but the PO is still the person who sets the priority of the backlog. The same applies to the the Team's involvement. Team members provide usable information on the technical level to the PO and the PO should be able ...
Neither PO nor Scrum Master is responsible, but the team is supposed to conduct daily standups. As a Scrum Master its your job to facilitate the team and make sure that process is being followed. Coach them to make the standups effective as opposed to having just mechanical updates during the daily ritual.
The Scrum Master ensures that the Development ...
The answer depends on whether this slows down or speeds up the process.
How many of the bugs she found were discovered during the Code Review phase?
If they were all discovered during the Code Review then maybe she's wasting her (and everybody's time). Though we can still ask:
How many of the bugs she found were fixed before the Code Review stage?
For the immediate future, you need to spend more time working with the Product Owner and less time focusing on the development team. You and the Product Owner both need to spend a couple of sprints refining your roles and learning to work together, and you both need to gain a better understanding of your respective roles in the Scrum process.
The estimate for an item should cover how long it'll take to be done. Assuming what you define as done covers testing as well as development, then it should be in the original estimate.
The best way to ensure everything that needs to be covered to reach done goes into the estimate is to ensure everyone involved (eg the testers) are invited to the sprint ...
Scrum says nothing about hierachy.
Thr Scrum Master position is not a higher position than the PO or the DevTeam position.
The idea is to not think in hierachy levels! Think about a team of peoply wanting to deliver high quality products!
There is no reporting inside thr Scrum Team. It's just not needed to report, because of the high transparency ...
While such a confidence check is nothing that you'd read about in Scrum Guide I don't see it as something that violates Scrum in any way. It is, in fact, answering a different question: the one about confidence of people, not the one about forecast end date.
The native method to answer a question about expected end date in Scrum would be based on Velocity ...
According to the Scrum Guide, the Daily Scrum is a meeting for the Development Team. It also says that it is the duty of the Scrum Master to teach the team about effective ways to hold a Daily Scrum, including teaching (and enforcing) the idea that any attendees from outside the Development Team do not disrupt the meeting.
Find out if the Development Team ...
Ideally the Product Owner will be present and will find the retrospective both interesting and rewarding.
However, if the Product Owner does not see their value in technical conversations then there are some things you can do:
Start the retrospective in the usual way but cover Product Owner related issues first, then allow the PO to leave and focus on ...
You're not wrong for writing the stories; it may be wrong in continuing to do so without change
Scrum doesn't say PO has got to write product backlog items or that they be user stories
Continuing serving, but do so by showing the cost of bad practice
Evidence, evidence, evidence.
For more good points, check out Venture2099's answer below for other ...
According to the book the product owner shall be present on the retrospectives, because he can provide very valuable information how the team performs from a business perspective.
Your fear is valid: if the boss is around the team members won't behave naturally and most probably their findings or ideas will favor the boss' expectations.
You could have a ...
It really sounds like the Scrum Master and the Product Owner have both bought into the velocity and utilization trap. Break the cycle.
Dissecting the Product Owner Role
The PO wants to know how many hours programmer X has available during each sprint and exactly what he will do with them.
Not his business in a Scrum shop. He is part of the Scrum ...
In a truly agile environment, does the PO go to the level of saying things like, "OK, we
have 40 person hours of work for Arthur and 32 person hours of work for Candace, and since
they're each supposed to be half-time on this project, they should finish that work by the
end of the next sprint." ??
Well, in a Scrum environment, or in any other ...
Change Control Isn't an Agile Scoping Tool
If he/she wishes to change the scope by adding in/taking out/re-prioritizing the Backlog the PO must submit a Formal Change Request/IOCA before taking an approved Change to the Scrum Master for Planning consideration.
This is the antithesis of agility. While Scrum works just fine in environments that require ...
The process you describe is pretty good and fits pretty well into Agile-scrum visual design practices.
Here's the visual design process that has worked well for me across several Agile-Scrum projects:
Start with rough wireframes 1-2 weeks before entering an iteration
Have your designer work with the PO to create the wireframes
Try and have the wireframes ...
I use MoSCoW prioritisation with clients (Must, Should, Could, Won't) and build developments around that. If the client would cancel the release if 'X' feature wasn't delivered, or if there is no workaround, then 'X' feature is a must.
Therefore the MVP is then defined by the list of 'Musts' in the prioritisation.
The PO is an importand member of the agile team, but should remain strictly within its role definintion, which according to this article :
The product owner, called on-site customer in XP and
active stakeholder in AM, represents the stakeholders. This is the one
person responsible on a team (or sub-team for large projects) who is
responsible for the ...
Waiting for the Product Owner to be away before having the conversation is not a good Scrum approach.
It is better to have an open discussion as a team and resolve the problem with everyone present.
If the team will not speak openly in front of the Product Owner then that is the problem that needs to be solved, not the Product Owner's behaviour.
While the Scrum Guide does not explicitly state whether the Scrum Master or Product Owner are, or are not part of the development team, they are part of the Scrum Team:
The Scrum Team consists of a Product Owner, a Scrum Master, and the development team.
Which infers that both the Product Owner and the Scrum Master operate outside of the development team....
1) Accept the fact that the PO needs help and that the developers are the most qualified people to help.
The product owner and the developers together form a team. Nobody's time is more or less important than another. They work together to develop software. The team can't be expected to use their valuable time effectively if they don't have good stories, so ...
You can do whatever you need to do, however removing stories is not advisable unless they are either wrong, duplicates or obsolete. The reason is that it takes time to write a story, and for you to read it and prioritize it.
Having a story you think is very low (or no-) priority at the bottom of the pile still has a value because it theoretically prevents ...
The Product Owner is the absolute owner of the Product Backlog. As such, he/she has the last word on what goes in, stays in, or gets out of it.
I wouldn't recommend to keep stories in the backlog "just in case." True, there is a cost associated with creating a story, but each item in the backlog will have to be maintained, reviewed, reprioritized, etc. and ...
In Agile Methodology, is a Scrum Master position higher than a Product Owner, in terms of organizational hierarchy?
The Scrum framework requires active collaboration between Scrum roles, and between the business (or customer) and the Scrum team. Hierarchical relationships within the Scrum team are antithetical to effective implementation of ...