56

If you aren't paying people, you really shouldn't expect them to stay around. If you want to give someone equity in exchange for payment; it should be a large amount of equity, and it should be spelled out in a contract, that stipulates the vesting period (if they aren't getting any money it should be an accelerated vesting period tied to milestones), but ...


26

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 ...


26

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 ...


22

The Product Owner is the person who is directly accountable to business stakeholders for the product and ideally is herself a senior business stakeholder or a nominated representative of a department or management team. It's often the case that they are also a business unit manager, perhaps reporting to a sales, marketing or operations director. Typically, ...


22

You don't make any mention of a Scrum Master in your Question, so I'm going to assume that either s/he doesn't exist or isn't helpful. If not, make sure you involve the Scrum Master! It's his/her job to address process issues. That being said, Scrum provides a tool to address things like this - the Retrospective. Here's what I would do, in your shoes. For ...


17

The PO is the owner of the product, but that doesn't mean they can do watever they want with the product. At the end of the day, they represent the needs and the wants of all stakeholders. Inevitably, you might end up in some situation where the PO has a different vision for the product than some of the stakeholders, but, like reasonable people, the PO and ...


16

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 ...


15

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? If ...


15

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 ...


15

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 ...


15

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 ...


14

That is a frustrating situation Chris. From your question, it doesn't sound like the team can't develop things in smaller pieces, but rather that they won't. I base this on the fact that it sounds like when the agile coach is there they do and just in my experience as a developer, the type of splitting you are talking about isn't usually difficult. In short, ...


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 ...


13

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 ...


13

The Scrum Guide does not talk about prioritizing the Product Backlog. Instead, it talks about ordering the Product Backlog. Priority is only one factor that can be used to determine the ordering of the Product Backlog. Dependencies between work items is another factor, but the Product Owner can choose any factors that are appropriate to help maximize the ...


12

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 ...


12

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 ...


12

To your overall question, while Scrum can be applied in most projects, it is not necessarily the best approach for some projects. That said, it is well suited to complex problems that require discovery of the solution and adaptation to new information. Your project sounds like exactly the kind of project Scrum was designed to tackle. However, you raise some ...


11

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 ...


11

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 ...


11

Yes, you absolutely want your PO at the Daily Scrum. First off remember that the Scrum Guide is something like 17 pages and only covers the broadest brush strokes. The product owner is part of the team. They are the direct connection to the business and the person who signs off on stories as done. You absolutely want the PO there so they know what's ...


11

I think the timing is important. During the daily scrum, he needs to focus on the "what". During the rest of the day, if he feels his experience (to juniors) is valuable, then there's no reason to stop him from dispensing valuable advice. But he cannot pollute the daily. Once he has to "walk around" to dispense his advise individually, he ...


11

This is a multi-faceted question, so I'll try to provide something helpful step-by-step. First, the Scrum Guide is just a guide, but it is the definitive guide on Scrum. Furthermore, it has been built and refined on decades of experience in companies effectively delivering products iteratively and incrementally. It is not the only proven approach by any ...


10

The Scrum Guide is explicit that this is allowed: The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.


10

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 ...


10

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 ...


10

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.


10

TL;DR 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 ...


10

Lots of good answers already, but one thing I think may be missing is customer feedback. Developers will initially be enthusiastic at solving technical problems, but to sustain their enthusiasm they need to feel what they are doing is worthwhile. The best way to give them that feeling is to ship your product to real customers and to get regular feedback. ...


9

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 ...


Only top voted, non community-wiki answers of a minimum length are eligible