In Scrum here is the rough breakdown:
Epic - something so big it probably won't fit into a sprint, is not clearly understood in terms of customer requirements and should be broken down into stories. T-shirt sizing is a common way to size epics. Another way is to say we think it could take X to Y iterations to do this work. Epics are usually defined during ...
An epic is like a super-story. When a story is too big to fit comfortably in a sprint and/or contains a lot of unknowns then it is usually better suited to be an epic. Epics are fine on the product backlog, but as they approach the top of the backlog they are typically decomposed down in to several stories. We don't bring epics in to sprints.
No Fibonacci Required
While many agile practitioners have embraced a modified or unmodified Fibonacci sequence for story-point estimation, neither story points nor user stories are actually requirements of the Scrum methodology.
Even if you embrace the practice of estimating with story-points and user stories, you can use any relative-sizing tools you want....
The only certain answer is: sometime before the story is added into the sprint. After that the story point estimate doesn't add much value.
Common times that Scrum teams estimate stories:
Backlog Refinement: In backlog refinement the team looks one or two sprints out to see what is coming up and prepares these stories to be brought into a sprint. ...
No, they would only make sense if you were writing a product where a "product owner" was a customer -- for example, a tool for keeping a backlog would have stories that start with "As a product owner" because a product owner would actually be using the product you are developing.
But normally, no. The product owner is generally not a customer/user of the ...
When estimating user stories, everyone should be estimating the complete effort it will take the team to get the story to Done. So, the back-end dev should not just estimate the effort it will take him to do his part, but his estimate must also include the effort for the front-end, the design and all testing (and similar for the other team members).
Working software over comprehensive documentation.
In general, I'd say that it just gets fixed and considered part of the work needed to complete the story. When you found the bug, you added a failing test to document it prior to fixing it, right? Right? Thats more than enough documentation for most use cases and doing anything more is useless overhead. (...
Research stories (called Spikes in Agile terms), should be:
always be time-boxed
Should we assign a time box (so many hours) for research stories or a regular point estimate?
Regular point estimate cannot be used mainly due to following reasons:
story points give out a measure of business value
points are used to calculate ...
One main reason is to not have debates/estimates like: 19,20, 21, 23 Story Points.
In agile estimation is usually about comparing relative size, it's clear that 1 Story Point is significantly smaller than 10 Story Points, but 10 SP vs 9 SP is not much different.
You want to make sure that bigger numbers are rough estimates and you're not sending to your ...
My question is, to what extent should the PO describe the requirements of a UI?
To the extent that the designers know what to design and the programmers know what to program. In your example, "as a user I want to see a list of dates so I can..." seems to be a good user story. Who else would know what the purpose of that user interface is and what data the ...
It is worrying that you have no why part to your user stories. This is an important element of the user story format as it allows us to evaluate the stories and to prioritise them. It appears that you are writing technical requirements but partially using the user story format.
I also notice that you focus the stories on the admin, when I suspect the value ...
The acceptance criteria you have listed are really a mixture of stories and tasks.
Given your example story:
As a user I want to register and log in so that I can register on the application and start using cloud memory
I would break that down in to:
As a user I want to register so that I can gain access to and start using cloud memory
As a ...
The Sprint backlog is a forecast, not a commitment
In the 2011 revision of the Scrum Guide Jeff Sutherland and Ken Schwaber made an important change. They changed the word "commitment" to "forecast" in regard to the Sprint backlog.
The term commitment has two bad consequences:
The stakeholders expect to have every single item delivered at the end of the ...
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 ...
Should we assign a time box (so many hours) for research stories or a regular point estimate?
You should do both. A spike (or "spiked story") requires both a time-box and a level-of-effort estimate, and is always counted as work.
Spikes Are Just Special User Stories
As one source states:
Like other stories, spikes are put in the backlog, ...
From the Scrum Guide:
During the Sprint:
No changes are made that would endanger the Sprint Goal;
Quality goals do not decrease; and,
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
The changes you mention fall into the last category, unless they endanger reaching the sprint ...
In general there are no rules but what you make. Your Product Owner would define what this means to them, then document and share it.
If you look as some of the scaling frameworks available there is a generally accepted hierarchy:
A Task is about the how and noone other than the team should be concerned with them
A Story is a what that can fit in a single ...
Writing automated tests should still be part of each user story, as part of your definition of done for each user story. A user story should not be called complete without appropriate tests written for it--it doesn't matter which order you complete the work in.
Just to expand on this a little more/clarify: don't call things done until they're done. If "Done"...
I would focus on the need, rather than the implementation. The user story would then simply be:
"As a user, I want any personal information I give (Company) to remain private and secure."
With HTTPS then being an implementation detail of that story. After all, if you found some other means of completing the requirement (such as not getting any personal ...
Yes, there is a difference as far as what a user story and what a use case is. There are a lot of references on these online (search use case vs user story), however EITHER can be used in terms of agile planning. I think what you'll find, at least in my opinion, that the user story is better suited for agile planning and development.
This is one of my ...
Neither of your stated options are truly agile. You are misusing points in an attempt to represent progress or to "hold people accountable." Neither is appropriate within the Scrum framework.
Points are an estimating tool. They are only meaningful in the aggregate, and are primarily needed for estimating team capacity during Sprint Planning. Using ...
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 ...
I would say no.
As you note, user stories should be vertical slices. Another way of looking at that is that they should, by themselves, provide value.
You should only burn down stories once those stories can provide value.
However, you may be able to split and/or rework stories. As a quick example:
Recall that stories do not contain implementation ...
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 ...
Titles should be short and pithy, but meaningful. Think of them as communications shorthand that give the team a handle to refer to, not as lengthy descriptors. The story labels should make it easy to differentiate stories from one another.
Effective Story Titles
What constitutes a good or bad title will vary a lot based on your organization and ...
Story points measure effort; hours measure time. They are not interchangeable. You're going to be better off estimating man-hours, ideal hours, or calendar days from the beginning.
Scrum may not be the right fit for you, either. Kanban or Lean might be a better approach given your IT Governance constraints.
Story Points Don't Fit Your Organization
It looks like you have a problem in the ways stories are written. Stories represent an aim which has a value for an actor.
If you think about the Mike Cohn version of user stories: "[The actor] wants to do [the aim] in order to get [the value]". If you can identify these three elements, the scope follows logically.
The conversation that needs to happen on ...
You can't be faulted for being confused. It is very common for organizations to try and directly match story points to a real-world measurement. This exactly defeats the purposed of using story points (and why I dislike Poker Planning for estimating).
A Story Point in simple terms is a number that tells the team how hard the story is. Hard could be related ...
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 ...
For agile projects, a basic formula for estimating budget is:
(totalStoryPoints / velocity * teamHoursPerSprint) + nonLaborCosts = budgetEstimate
The results should be reported as an estimated range using statistical confidence intervals or a "high, low, average" method.
Estimate Budget Using Iterations
The "secret" to estimating agile budgets is ...