We’re rewarding the question askers & reputations are being recalculated! Read more.

New answers tagged

2

I would go with the approach - that has been highly appreciated by our professors, of having a simple user story which is split into multiple task. For example take a user login use case. User story : As a user I would like to login into my account.(This gives really high level view of a user story) Splitting it into multiple dependent tasks like: 1) Set-up ...


1

INVEST is a guideline and not a rulebook. As Scrum teams we endeavour to make as many of our stories as possible follow the advice from the INVEST mnemonic. You have wrapped some setup technical tasks into the first story, but there may well be nothing stopping you from moving them to another story. Say, for example, in the first sprint planning meeting ...


2

Tying into Daniel's answer, several Agile methods allow for aggregating stories into a larger story some call an "epic" that describes a larger deliverable like a feature. Each sprint does deliver a "potentially releasable" outcome--a variant on Daniel's phrase--like the "account section" you describe. And there often is value in showing that to the customer ...


6

Think "Release" Instead of Stories to Track Value User stories are not meant to be a measure of business value. As a rule of thumb, each Sprint should deliver a potentially-releasable increment of product, but nothing requires that each iteration deliver X amount of value. User stories just represent INVEST-sized units of work that collectively deliver the ...


5

The short answer is that there are many different cases where delivering a complete, market-ready segment of functionality is not reasonable in one sprint. So, let's start with the simple answer: each of those things you list is valuable to the customer and you could make it "potentially shippable" in the sense that it is technologically and quality-wise ...


Top 50 recent answers are included