I am trying to start a new app and want to follow scrum. We are using pivotal tracker, and we had added many stories and estimated them. We tried breaking stories to the smallest possible value deliverable, using verticle slicing. The tracker has defaulted to 20 points as our velocity for a 2-week sprint and hence there are 5 stories in our sprint.

As per what I understood by reading various content online, we need to make user stories that follow the "INVEST" principle. Since the app will be built from scratch, it requires some setting up tasks for e.g. setting up configurations, basic logical layers, etc. As per the "INVEST" principle, every story should be independent and to follow this, we decided to add these tasks in a single user story, the first story. But now the next user story is dependent on the previous story since we can't start any story without a basic app setup. This is violating the "INVEST" principle. Any suggestion what approach to take here?

  • Hi nak, thank you for starting to contribute to this community. Can you share the User Stories you're saying that are in conflict with INVEST? Nov 5, 2019 at 12:43
  • 1
    Hi, the accepted answer seems reasonable. Thanks
    – nak
    Nov 6, 2019 at 14:17

3 Answers 3


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 it is decided that the story you had originally proposed adding the setup tasks to was no longer a priority. You could move the setup tasks to another, higher-priority story and then re-estimate.

I recommend you go ahead with your original approach.

  • Thanks for clearing it out. It seems a reasonable explanation.
    – nak
    Nov 6, 2019 at 14:16

I always start these with product descriptions like this:

Name & No. Purpose of the product. Components of the product. Development skills required to build and or design the product. Quality Criteria of the product. Flexibility allowed on the quality criteria. How the quality will be checked. Who is responsible for the quality checking.

These can then form the basis of user stories AND the basic functionality that does not warrant the user story route because it is usually blindingly obvious why the basics are needed.


Following INVEST is guideline for writing stories so that you can include and plan them in sprint with ease.

Story describe a business value not technical approch, so that you can provide a value to your increment.

Any technical details can be included in the tasks of the story itself or in the first sprint (sprint 0) if it need to be addressed first like creating project structure, DB, git repository ...etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.