87

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 ...


47

Epic 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. Story A ...


33

With that much variation in the estimate, it seems like the work as it's currently defined is not ready for estimation yet. Based on that wide spread in estimates, I would say that the team doesn't have a clear understanding of what is required to complete the work. Unless the work was critical and must be started and get to done as quickly as possible, I ...


32

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....


23

The first thing you should do is encourage the team to bring concrete arguments. "Things are more complicated than they seem" or "I dont think those complications are valid" are very vague arguments. "I disagree, because the database-adapter has 3.000 lines of code, so changes in this class are very hard" or "Finding all methods doing X takes a long time, ...


20

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). The ...


20

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. ...


19

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 ...


19

If you do development work in the sprint, you should estimate. If you don't, then it's better you skip on providing your own story points estimates. You can help your team with information and advice, and support them to reach consensus, but you should let the people that do the work perform the estimates, otherwise you might be influencing them in one ...


18

TL;DR 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 ...


18

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 ...


17

Research stories (called Spikes in Agile terms), should be: used sparingly kept short 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 ...


16

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. (...


15

TL; DR 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, ...


15

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 and As a user I ...


15

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 ...


15

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 ...


13

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 ...


13

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 ...


13

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 ...


13

TL;DR 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 ...


13

I've seen this happen with design so many times. It's a structural problem with how people and teams are organized. Now, I feel like I should say that cross-functional teams are not required to be agile. Scrum does require them, but I don't see that you are specifically using Scrum. That said, the structure of "Design team creates some design and the ...


12

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 goal. If the last ...


12

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 ...


12

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 ...


12

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"...


12

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 ...


11

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 ...


11

TL;DR 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 ...


11

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 ...


Only top voted, non community-wiki answers of a minimum length are eligible