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


25

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


19

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


17

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


15

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

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


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

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


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


11

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


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

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

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

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


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

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.


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


9

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.


9

US3 and US4 seem to be the same thing to me. If you need to display the last 5 messages, then that means saving them somewhere, so US3 should somehow deal with that. If US3 does, then US4 is redundant and not needed anymore. But why do you think you need a database? As the PO you should not care about and/or decide on technical implementation details on ...


9

She does not give acceptance criteria This is not a problem if the Product Owner is happy to talk through the stories with the team and clear up any details. The team can even create their own acceptance criteria as a result of the discussions if they find that useful. If the Product Owner is not willing to spend the necessary time explaining the stories ...


9

Equity only? Well, you haven't made it clear just how "good" (your word) the equity is, but yes, likely the lack of anything tangible in terms of compensation is one of the factors involved here. But it's probably not the only one. It also sounds like you are running a virtual team, so it makes it easier for the individuals to fade into obscurity because ...


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