11
Identifying the Story's Primary Consumer is Acceptable
The term "user" in user stories is often better understood as an actor or role in a use case, or even simply as a value consumer. The primary goal of having a clearly-defined role in a user story is to frame the story to constrain scope. The secondary goal is to ensure that the user story is seen as a ...
4
In order to do Sprint Planning, you first need a Product Backlog. What you have is not sufficient to act as a Product Backlog.
The Scrum Guide defines a Product Backlog as "an ordered list of everything that is known to be needed in the product". It appears you have this, but Product Backlog Items are more than just brief requirements. Product Backlog Items ...
4
TL;DR
You don't describe your role on the Scrum Team, but the solutions require the active collaboration of all members of the team. In particular, the Scrum Master role is the process referee, and not simply a bystander separate from the rest of the Scrum Team. This is often obscured by a misunderstanding of the "servant leader" paradigm. As a coach and ...
4
Welcome to PM.
One of the most influent persons in this world, Mike Cohn, wrote an article about it back in 2015 you should definitely read with name Not Everything Needs to Be a User Story: Using FDD Features. Some of his articles were used to provide good answers to questions within this community and it also suits yours.
The article name mentions author'...
answered Dec 5 at 19:24
Tiago supports GoFundMonica
1,2852 gold badges6 silver badges29 bronze badges
3
The two approaches actually solve different problems and are fairly compatible with each other if you happen to have both problems.
Scrum
Scrum is designed to solve complex-adaptive problems. That is, problems that are difficult or impossible to quickly identify the best solution for, moving targets, and problems where you understand the problem better the ...
2
Are stakeholder and users separate roles on a project in Scrum or they are covered by Product owner?
In Scrum, there are only three roles - Scrum Master, Product Owner, and Development Team member. Scrum does recognize stakeholders - the Scrum Guide talks about them in several contexts, such as the Scrum Master working with stakeholders to help them understand how Scrum works and how to best interact with the Scrum Team and stakeholder involvement in the ...
2
I'll add my voice to Bart and Daniel, and go a step further: I do not use the MoSCOW method at all for the very reason of eliminating the confusion you are feeling. My teams had no trouble, and actually preferred just getting a rank-order like Bart describes. I have POs use whatever method they like to determine the business value for rank ordering, but ...
2
I don't see that SAFe and traditional agile are really comparable in an apple-to-apple sense.
Traditional agile is terrific and when in doubt doubling down on the agile framework is a great idea. But at a fundamental level when you need to have 10 agile teams working in the same direction on what's essentially the same initiative you need a way to ...
2
You have a lot of extraneous information in your question. If you have a prioritized backlog, we can assume that doing the work in the order given will provide the highest ROI. Therefor, unless the team has specific reasons that the order must be changed, I'd look for them to pull in the first item, then the second if it fits, then the third, and so on.
Now,...
2
Work in Progress is a critical part of Kanban because of Little's Law. You are welcome to read more about it, but the short version is it shows a direct relationship between throughput, response time, and work in progress. By limiting your work-in-progress and focusing on flow (and prioritizing getting things to done over getting started or keeping people ...
2
Limiting work in progress is a cornerstone of Kanban because:
It helps to emphasise that Kanban is a 'pull' process
It is often a very effective way to improve the throughput of work for a team
It is simple and easy to implement
It combines well with another feature of Kanban: visualisation of a process using a Kanban board
2
Visualize the Workflow and Manage Flow are related, but different, concepts.
Visualize the Workflow means to make the process by which work gets done visible. This is often done with a Kanban board, where work items are represented by cards and states of work are represented by columns. Kanban boards also make work-in-progress limits visible. You may also ...
2
Scrum works well for projects that:
Have relatively stable requirements - such that they don't often need to be changed inside a sprint
Team sizes from 3-9
Have a stable team that has the time to learn and adopt a framework
Benefit from a regular time-box (the sprint)
Kanban works well on projects that:
Have changing priorities
Frequently have new ...
2
User stories are a tool for understanding and fulfilling user needs. I could change that last one to say "As a paying user, I want my logins secured so I don't get charged for unauthorized use of my account."
There are other mechanisms like the Definition of Done for quality concerns like availability, testing, etc.
Also, Scrum does not require the use of ...
2
You have some great answers already, but I just want to add something. You say that your stories:
aren't really end-user driven in the traditional sense
I'm not sure that is the case for all the stories you list.
For example:
As a Business Owner I want regular database backups so that we can maintain business continuity
Yes, this is important to the ...
2
The first thing I would do is make a distinction between the role of Business Analyst and the skill of Business Analysis. This may seem like an unimportant distinction now, but it will pay off long-term.
In Scrum, and in SAFe, there is an expectation that teams are engaged in uncovering and identifying the requirements. This absolutely requires the skill ...
2
You may want to consider getting the team together and coming up with a working agreement.
This will need to be decided on by consensus of the whole team. The idea being that when people actively participate in drawing up a working agreement they are far more likely to follow it.
It is a lot easier to call people out for things like being late to meetings ...
1
I suggest to apply fine, for every minute late, there will be a constant value for the fine example $5, but first you have to agree on this rule as a team, because scrum and agile project management depends on self organize team, and suppose to be funny, as the team knows the important of time-boxed events and the harm of being late, it will be easy to agree ...
1
Having a productive development team and getting the right kind of engagement with stakeholders are what matter. If those are in place then the team can decide for themselves what documentation is useful. A single answer is not going to suit all projects and the same documentation won't necessarily be appropriate for every situation on a given project.
A ...
1
Henrik Kniberg and Mattias Skarin have written a short book about similarities and differences between Scrum and Kanban, if you are interested. There is also a summary from Henrik Kniberg found here. For a TL;DR you can jump to page 48 of the summary where you will find this:
If you look at the Kanban differences, where there is no lock down into iterations ...
1
Visualising the workflow helps the team to manage the workflow. The visualisation allows the team to make changes and see the impact the changes have.
There is a good argument that managing the workflow would be difficult to do without a good visualisation.
However, visualising the workflow also has other benefits, such as:
It helps the team to ...
1
Kanban originated in the manufacturing industry
In the manufacturing industry excess Work in Progress (WIP) has many disadvantages:
High inventory carrying costs
Risk of obsoletion
Risk of dead inventory when a different model is scheduled
In the Kanban system you keep only enough Finished Goods (FG) inventory to meet actual demand. Working backwards, at ...
1
I believe the following quote is clear:
Limiting WIP is the cornerstone of Kanban. Limiting work-in-progress
implies that a pull system is implemented. Put limits on columns in
which work is being performed. The critical elements are that
work-in-progress at each state in the workflow is limited and that new
work is “pulled” into the next step ...
1
Pages can be restricted to specific users. Take a look at: https://confluence.atlassian.com/doc/page-restrictions-139414.html
1
Are stakeholder and users separate roles on a project in Scrum or they are covered by Product owner?
Users ARE stakeholders
A stakeholders, by definition, is anyone who "holds" a "stake" in the project/product. And the term is broad, meaning also anyone who is affected by the project/product.
Some stakeholders are more important than others. They are called Key Stakeholders, and might be the project sponsor for example, or a product manager that decides ...
1
According to the Scrum Alliance as well as to the Scrum guide there are 3 Scrum artifacts: the Product Backlog, the Sprint Backlog, and the product Increment.
As far as Scrum itself is concerned, there are no more artifacts there. Of course you can modify Scrum in any way. However, I'm not sure that it still could be called Scrum.
1
The Scrum Guide is the definitive guide of what artifacts are in Scrum: The Product Backlog, Sprint Backlog and Increment.
It would certainly be possible to make a case for the "Definition of Done" or "Sprint Goal" being artifacts, but that is not stated explicitly in the Scrum Guide.
As Scrum is a framework it leaves a lot of room for adaption. Hence you ...
1
I'm not exactly sure what you are referring to, but what you are describing seems similar to the Weighted Shortest Job First (WSJF) from the SAFe framework.
WSJF is a way to define the priority of features that need to be built and decide in what order to build them. It takes into account the fact that features that sit idle on the backlog with nobody ...
1
To determine which approach to use you need to dig into the implemented product architecture (not by yourself but with the team) and try to map its relevance with product's roadmap.
In case you understand that architecture and technologies used for the implementation are still relevant for the further product growth:
should I create my release around the ...
1
MoSCoW is not typically a good way to prioritise a backlog. Firstly because it isn't fine-grained enough. Having just four fixed categories becomes insufficient as soon as the stories in any one category exceed the capacity of a sprint. Secondly, "absolute" categorisation like MoSCoW risks giving stakeholders and teams the wrong mindset. It may prompt some ...
Only top voted, non community-wiki answers of a minimum length are eligible
