16
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 ...
15
TL;DR it is a project.
Let's take a look at the definitions of the "project".
PRINCE2:
A Project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case.
PMI:
A project can be defined as a temporary endeavor undertaken to create a unique product or service. Projects ...
15
Definitions Must Be Localized
I am using a project management system that forces me to define feature requests as either High, Medium or Low priority. Has anyone got a good set of definitions that clarifies what those priorities should mean?
They mean whatever your organization wants them to mean. How any given organization prioritizes features or tasks ...
8
The Product is the thing that you are building, or the service that you offer, or the need that you want to satisfy, or the vision that you have. The Product is first and foremost an idea "to do something". Only then you can you make it happen. And only then you can decide how you will make it happen.
Like putting together a Scrum team, for example....
7
TL;DR
Research and science projects are certainly "projects" from a project management perspective. Your friend owes you the socially-appropriate beverage of your choice if you two were betting on the issue.
Defining a Project
Wikipedia defines a project as follows:
In contemporary business and science a project is defined as a collaborative ...
6
User stories are an Agile approach to requirements that emphasise end-user value.
All user stories are written in the language of the end-user such that they can be understood by a non-technical person who will instantly 'get' the value the story delivers.
The reason this is done is that it helps the non-technical end-users understand what progress the team ...
6
I really love Wikipedia for definitions:
https://en.m.wikipedia.org/wiki/Governance
https://en.m.wikipedia.org/wiki/Strategy
In summary: Governance includes everything to rule the project while strategy describes the way to achieve the project's goal.
Having this, the project's governance should support or even follow a strategy in order to achieve the ...
6
Management by surprise.
One thing you might try is each time your boss comes in with new urgent tasks you ask him: "Which of the tasks we have already agreed on should I drop in exchange for the new one?"
https://www.vitalsmarts.com/crucialskills/2015/01/dealing-with-a-last-minute-boss/
6
Self-organizing teams is a trend in the professional world for some time. An increasing amount of organizations are turning to self-organizing teams to increase ownership, teamwork and collaboration.
The typical structure (what many envision when talking about self-organizing) for these teams is the “no leader”-approach. In this approach, teams adopt a ...
5
According to the PMBOK, a Portfolio is a collection of projects or programs and other work that are grouped together to facilitate effective management of that work. So, with only one project, strictly speaking, you also have one portfolio. Also you probably wouldn't call it that...
Portfolio Management then becomes the centralized management of one or more ...
5
There is, of course, difference between method and methodology terms, since etymologically methodology is theory of methods.
Saying it simply and not being entirely accurate, a method is a way of doing things, and a methodology is a collection of methods.
Dictionary definitions describe briefly these terms:
methodology: A set of methods, rules, or ideas ...
5
User stories should be vertical slices that deliver value to an end user. The system is a mindless machine that doesn't care about value so user stories that start with 'as the system' generally will not help you understand why we are doing something from the perspective of the business or a customer.
So there will be stories where you will write 'as the ...
5
Ask the person asking you.
This advice applies in general - whenever someone uses a term with which you are unfamiliar, ask them what it means.
This carries a slight risk of making you seem ignorant. Which is far better than the large risk involved when making an incorrect assumption, which can end up being costly to the project.
Not to mention, it's ...
5
It's a good question. From a Scrum point of view the product backlog and the sprint backlog together encompass all the things that are being done or that are on the list to be done in future. So the term backlog refers to the full list of items no matter what their status. Status information is usually shown against each item on the backlog.
However, I do ...
4
While user stories can absolutely be considered a type of requirement, there are distinct differences between user stories and other requirements that I don't see here or in the accepted answer on the Software Engineering site (though it is touched on in other answers).
Most important amongst those differences is the way in which they encourage the team and ...
3
I don't believe that the two are mutually exclusive. Something can be wasteful to varying degrees and be cautious and be valuable. While not completely subjective, I'm not aware of a particular measurement to indicate that something is wasteful. One definition I saw for waste is: “useless consumption or expenditure; use without adequate return.” In other ...
3
Yes, as a product owner who writes user stories all the time for a VERY large project that is considered an agile pioneer in our industry, I can say that we would never write "As a system..."
A user story is a story about a user. If you drill down through the logic of why something is needed, there is always a human under there somewhere and that person is ...
3
I don't think there is a universally well defined difference, but usually "methodology" is used to mean something bigger, more complex and/or more detailed than "method".
In my experience, Agile folks don't like the term "methodology" much as it has been traditionally associated with complicated, top-down organized, fundamentally un-agile processes like ...
3
Interesting question, I have given it some though now. I think you make one wrong assumption, and that is why you are confused.
First, a very simple and practical, but not fully correct, answer: some sites suggest that model in this would be the same as method (so the first option; e.g. http://istqbexamcertification.com/what-are-the-software-development-...
3
From a great article on the subject at https://theprocessconsultant.com/process-project-even-matter/:
Processes are repeatable. Projects are one-offs. In detail:
Projects are one-offs. At the very least you perform them infrequently. Yes, I know there are such things as project templates. That kind of implies that projects are repeatable. If you are ...
3
It's best to think as user stories as a sub-class of requirements.
IEEE and IIBA both use a three-part definition for what a requirement is:
a condition or capability needed by a user to solve a problem or achieve an objective
a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard,...
3
Disclaimer: This comes from my experience on the financial sector. It may or may not be applied to other areas, as some expressions are very common on specific industries but not used in others.
Fire-fighting management.
As described by this hbr.org article, firefighting is the working "model" where
Managers and engineers rush from task to task, not ...
3
By this brief description, it sounds like you company is busy, has a strong client base and healthy demand; it sounds like your company is staffed lean and mean; and deadlines are not a critical success factor, i.e., your clients are still providing a healthy demand despite their work being delayed. Perhaps your company is bringing in a healthy profit, as ...
3
I like to think of a product as having a distinct set of end users who derive value from its use.
end users -> People that derive final value from the product, not people that will use the thing to make another thing (i.e. it is not a component)
distinct set -> Identifyable group of people get value from it, not 'the company' or some other ambiguous entity
...
3
Barnaby Golden's answer points to the trust associated with a product, which is very interesting and goes hand-in-hand with what Tom Graves writes in Product, service and trust:
A product represents the promise of future delivery of (self)-service,
via use of that product.
(...)
When we obtain a product, we trust that that product will deliver ...
3
Effectiveness is doing the right things.
Efficiency is doing things right.
This is something I heard from Scott Hanselman. The larger quote goes like this:
Effectiveness is doing the right things, but efficiency is doing things right. That means effectiveness is picking a direction and efficiency is running really fast in that direction.
One is ...
3
Milestones: Terminal Nodes of Major Project Activities
Think of milestones as major markers along your path to project completion. Much like mile markers along the side of the road, a project milestone tells you where you are in your overall project journey. It may be easiest to think of a milestone as a measure of progress or important inflection point ...
3
Disclaimer: The first time I read the question, I thought it'd have a straight answer. After reading it again, it may not be as straightforward as I originally thought (or maybe I'm overthinking).
From Cambridge dictionary, a backlog is a large number of things waiting to be done.
Therefore, once an item is no longer waiting to be done, it shouldn't be ...
3
I think that having an answer to the question is more important than what the answer is.
Decide on what you believe is the purpose of the backlog and make sure it is communicated widely. Work with it for a while and see how things go. If you experience issues, adjust the way the backlog is defined and again make sure everyone is aware of the change.
2
In short, not necessarily but it does have a "bad smell."
It sounds as the root issue is that they might be poorly written and, more importantly, are poorly understood. I sounds like there needs to be improved communication regarding the purpose and goal of these items.
Only top voted, non community-wiki answers of a minimum length are eligible