Hot answers tagged

24

Backlog Ownership The Product Owner owns the Product Backlog, and prioritizes it on behalf of the stakeholders. The Sprint Backlog is the property of the Team, and they are the sole arbiters of its contents. Contents of the Sprint Backlog The Sprint Backlog contains user stories popped off the top of the Product Backlog during Sprint Planning. However, ...


7

Product Owner is required to develop a release roadmap Contrary to popular belief Scrum does not mean seat-of-the-pants management with no advance planning. The Product Owner is required to develop a release roadmap. However, there are two key requirements for a release roadmap in Scrum: The timeline in the release roadmap should be based on actual ...


6

This is an excellent question and a refreshing change form the typical project management fodder we get here. I am a former coach for Lean Startup Machine and a previous winner of Lean Startup London so I can offer you some guidance. TL;DR If customers do not click on your adverts then it is a target audience problem (Funnel Stage: Discovery) - find a new ...


5

Per the Scrum Guide Page 5: The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.


5

The Product Owner is not a mandatory attendee at the Daily Scrum, which is only for the Development Team. If the Product Owner does turn up, they should not speak or take any active role in the meeting. A Product Owner reflects the wishes of the stakeholders and is the single decision maker in terms of ordering items on the product backlog. They can appoint ...


5

•How many people (this includes programmers, designers, project managers, etc.) does this scope of a project usually involve? •What would be the ballpark cost for developing this kind of app? Assuming that you are the customer for this App these are questions better asked by sending out a request for proposals to several vendors who can produce this ...


3

See my comment above; I think the answer is highly localized to the company. I'm going to suggest two levers that could be used, but either of these could be a career ender in your company. The core of the answer is that you are responsible for project closure, not completion. If the project is going to fail it is in the company's best interest (and your ...


3

You're not completely incorrect in your impression of the Sprint Backlog. The Product Backlog is the tool used by the product owner to keep track of all of the features that stakeholders would like to see implemented in the product whereas the Sprint Backlog is a subset of the Product Backlog representing the current active Sprint iteration. From The IT BA - ...


2

There are a lot of variables in your situation that I don't know the answer to and so I'll try to keep my suggestions as high-level as I can. Either way, please use them as only a starting point. 5 Levels of Planning First I'd look at the 5 levels of planning. There's a lot of info to look up on this, but the short version is that they are: Vision ...


2

Short answer is no. In my own experience, this is the myth of requirements. I've never found a business or project team that can clearly articulate what they want at the beginning of a project. This gets worse if they've never done the kind of project that you're undertaking. Agile or a full-blown requirements package are just two different ways of ...


2

Agreed, you will certainly have multiple stakeholders from in and out of the organization, but only one Product Owner -- whose role calls for her to represent and prioritize based on these various interests.


2

The Product Owner doesn't need to care about Tasks. You should not be creating them. You should not be looking at them. You should not care about them. You create and prioritize the Stories. The Team then creates Tasks and Sub-Tasks. The Team must update Stories when they finish working on them. There is no such thing as a 'half-finished Story'. A Story ...


1

agile project: either the first iteration of a brand new solution leading to an MVP, or a timeboxed mission to achieve a specific scope/goal I am struggling to see why this is necessary and why the Agile product evolution approach you mention cannot be used instead. A brand new solution can be developed using an iterative evolution. You may decide to not ...


1

Definitions Matter: Project Management vs. Business Products It looks like some of your confusion stems from terminology. What you seem to be doing is developing a use case or business justification, rather than defining a project or product. From a project management perspective, a product is a deliverable or outcome generated by a project. In other words, ...


1

It depends on the perspective. From the perspective of the law firm, the IT department provides a service to them that enables them to provide their product / service. However, from the perspective of the IT department, their product / service is the tools and technology that enable the broader organization to function. So, from the perspective of the IT ...


1

Documents live and die by organization and relationship, so the hierarchical approach scales better. For example: Earlier this year we made the AWS SDK developer guides available as GitHub repos (all found within the awsdocs organization) and invited interested parties to contribute changes and improvements in the form of pull requests. Today we are adding ...


1

from the scrum guide scrum guide The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management ...


1

You can influence the product process only by stressing that the project mgmt process is only as good as the information that goes into it. If there's a deadline, then remind everyone that that the project can't start until the requirements (scope) is known and delivered to the team. The clock doesn't start ticking until that happens. The adage of ...


1

The hierarchical relationship between a Product backlog and sprint backlog is caused by the iteration configuration in your timeline (by making sprint iterations children of the release iteration). Each timeline can have one Backlog iteration (that would normally be associated with the Product Backlog). I can't think of any advantages to making the Scrum ...


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