There is no change request for the prior lightbulb; the change from "lit" to "dark" was not authorized.
I have tasked the team from seven parallel lines to perform an root cause analysis and produce an Ishikawa diagram. They have had to replace the lead tech who apparently tried to assault the project manager with a chair.
A second team has been ...
While they seem similar, there are distinct differences.
Product Management has to do with the 'product' itself - design, features, audience, pricing, marketing, profitability, etc.
Project Management focuses on delivering the product.
Example - The intended market needs to be researched - the act of researching (who to research, how to conduct, what ...
Other than Projects tending to be short-term and Products tending to
be ongoing endeavours, is there a difference in the two?
The key difference is fairly simple:
Product management: is responsible for discovery and definition of the scope.
Project management: is responsible for execution and delivery of the scope.
Exporting to Excel is a solution, not a requirement. You need to go back to the owners and get them to detail their functional requirements for the data. Once done, then hand it over to the developers and let them propose a solution. It may end up being Excel because, as you wrote, it's already there, or it might be another solution that meets the ...
Does the Product Owner comes from the software company or from the customer?
It does not matter as long as that person is good in the following aspects:
Most importantly, PO needs to have a vision of what is to be built and why. For this, PO should have good communication with sponsors/stakeholder and should also be able ...
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 ...
Yes. Using 'the system' as a user in stories is bad.
The whole point of the "as a ... I want ... So that ..." Format is to give the developer an insight in to the reason for the requested feature. This should allow them to fill in the gaps in the specifications.
Rather than "make the button red" you would have "as a customer i want the buy button to be red ...
Projects don't have to be short-term; they can be long-term. The only requirement for a project is:
it must produce something, and
it must have an end. If it takes 2 years or 2 weeks to finish it can still be a project, and fall under the domain of the project manager.
I tend to think of product managers as being a special case of the project manager, a ...
Kanban certifications are definitely not as well established as Scrum training/ certifications. But they certainly are available.
The Lean Kanban University, with active involvement of/ direction by 'Kanban Method for Software' pioneer David J Anderson, has been issuing 2 kinds of certifications - AKT - Accredited Kanban Trainer - and KCP - Kanban Coaching ...
I respectfully disagree with @DavidEspina. I don't think his answer is fundamentally wrong, but it doesn't match my answer.
During project initiation (or in some contract work, prior to project initiation) you determine the scope of work. This is the box inside which all requirements must fit. The project sponsor and project management team must strongly ...
As a principle, whether having an Excel is "worth" (business-wise) or not isn't up to the development team to decide. They have to be able to tell whether it's feasible, and objectively tell what are the pros and cons (i.e. it won't work when you have more than 1.000.000 rows of data), they can also advise the client on whether this really solves their ...
Unless the light bulb was to be changed as part of a planned upgrade from incandescent to fluorescent, then it's a BAU issue and not a project. Yes, I know LEDs are the way forward, but we prefer to avoid being at the leading edge so will wait at least 4 generations before we trust that new-fangled technology.
I actually have to disagree to some extent with David Espina. It is essential in Scrum to understand who owns which piece of the process.
The Product Owner owns the Product Backlog. It is their job to prioritize the highest-value items at the top, to express their vision clearly to the Scrum Development Team, and to ensure that high value is being produced....
First of all, I'd like to congratulate you for being worried about the quality of your relationship with the newbies. It makes me assume (and believe) you're on the path to be a good lead on the long term.
Things I believe you must have clear in your mind:
- You cannot do two things at once: as @JonnyBoats stated, you must not expect to be a dev leader ...
First of all, it is not entirely your fault that the project went over schedule. As they asked, you did the best you could given the resources available. You told them the risks, and they agreed with it. The only points you should have taken more care of is that you took one month (1/6 of the time available) to figure out that the other guy had no prior ...
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.
Product Specifications vs. Project Scope
One assumes that you're not looking for dictionary definitions. We have Merriam-Webster and Wikipedia for that. For practical differences, I would suggest the following perspective:
Requirements are the things your project needs built, and specifications are the instructions for what the things you want ...
Practicably infinitely many. The more basic question might be who, chosen or appointed how, is supposed to safeguard the replacement light bulb(s) against such untoward eventualities as would occur were each or all dropped, stepped on, or otherwise broken.
Beyond the project managers and their staffs and accountants, and beyond their attorneys and their ...
They have a concept for a piece of software, we do some analysis and agree on reasonable budget and start agile development.
However once the client starts to see the product they cant (sic) help but tweak endlessly
despite our protests
Why are you protesting? If you're in an agile environment, you are supposed to embrace change, ...
How to share developers between multiple agile projects?
You don't. Doing so is inherently non-agile.
This smacks of an X/Y problem, where X (the real problem) is likely to be an executive mandate to "do more with less" without prioritizing projects based on both business value and resource constraints. However, you or your organization may have ...
I think there are two questions here.
First: Can the Development Team formulate new suggestions from this site?
You can make a weekly or biweekly meeting (name: Grooming) (time box: half hour) where you can collect all new suggestions.
Second: Can the Development team vote for or against certain suggestions?
It will be better to push ...
Is it necessary to have that many versions? Is there a way to change to one track? (One track means that you have one main or master branch depending on your version control system and every change goes into that main or master branch, and there are no versions)
If it is not necessary, then I suggest to forget about the versions and iteratively deliver into ...
Typically my preference would be to build teams around products, target customers or target markets. In that scenario product management would be just a different part of a team that also includes all the engineering roles. That, however, might not be feasible.
Some organizations, the one you describes seems to be one of them, are organized along functions, ...