55

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


22

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


21

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


20

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


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


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


13

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


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

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


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


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

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.


9

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


9

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


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


9

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


9

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


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