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 ...
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.
If customers do not click on your adverts then it is a target audience problem (Funnel Stage: Discovery) - find a new ...
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.
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 ...
•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 ...
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 ...
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.
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:
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 ...
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 ...
In a globally competitive marketplace there is no place for complacency
With technology providing a global reach from any corner of the globe, you don't know where your next competitor is going to emerge.
Is there always a next step?
Yes, there is. Are you growing? Even if the answer is yes, you could be growing faster. Are you gaining market share? Even ...
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 ...
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, ...
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 ...
You're focusing on the process ("data-driven decision making") and not on what you actually want to accomplish (a better product). You should try it the other way around.
Start by thinking about your vision for the product. Where do you want it to go? How do you want people/customers to think of it?
Then start thinking about how you might recognize ...
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 ...
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 ...
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 ...
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 ...