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 ...
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 ...
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 ...
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 ...
I am assuming you are using a Scrum process, but the core of the answer will not be significantly different for other agile processes.
The core of your problem lies in that you try to coordinate the work within a team or between teams on a technical level without understanding all the technical details. The solution here is not a particular template for ...
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 ...