How to execute sprint effectively?

  1. If my story is developed , tested i.e. unit + acceptance + regression, all the bugs are resolved i.e. even low bugs then only developer take on another story? Or we can submit in UAT with open low bugs?
  2. When is the best time to write automated test cases - I understand that unit testing automated test cases is written in parallel but when should functional or regression test cases be written. I am asking this question so that I hire my team resources accordingly. I believe when system will be somewhat ready after 2-3 releases then i will hire automated testers.
  3. Is there a practice of creating Technical Stories against Business Stories?
  • Please focus on ONE (1) question per post, and ensure that you've done enough research and provided enough context to make your question narrow enough to allow for a canonical answer.
    – Todd A. Jacobs
    Commented Oct 24, 2015 at 20:05
  • CodeGnome they are small questions of sprint execution so i have asked together. Let me know if there is any specific question which you feel is very big/requires separate discussion and that it can not be part of this and i should take it out.
    – Roop
    Commented Oct 25, 2015 at 6:22
  • @Roop there is a search box in the top right corner - go ahead and dig yourself within hundreds of questions. Commented Oct 25, 2015 at 9:12
  • Bartek Kobylecki thanks for telling.So far i have already read around 100 questions .It will take some time. These were some small questions I have asked , i hope community can guide. If you all do not like my question , you can decide to close.
    – Roop
    Commented Oct 25, 2015 at 10:54
  • 1
    @MarkPhillips , as asked by you i have broken this question into smaller questions and asked new questions
    – Roop
    Commented Oct 28, 2015 at 14:42

1 Answer 1


That's a lot of questions! Answers in sequence below:

  1. The decision on when to submit for UAT should be made as a result of conversation between the team and the Product Owner. There may be times when the Product Owner decides that bugs are not important and do not need to be fixed. The final decision on when to go to UAT will always be made by the Product Owner. Note that we try and do UAT as much as possible within the sprints, so frequent, small UAT is preferred over waiting and then lumping lots of stories in to UAT together.
  2. The value from automated tests is that they reduce the need for manual testing and help to discover bugs very soon after the code is written. For this reason, automated tests should be written as early as possible. A lot of teams will write the automated tests at the same time as they do the development work. Some teams even write the automated tests before they do the development work.
  3. In Scrum we try to make every story business focused and delivering some business value. If there is technical work required, we often cover this in sub-tasks that relate to a business story. The reason for this is that we want to measure progress in terms of delivered business value. It also helps the Product Owner as they understand the value of each and every story.
  4. As much as possible we try to write stories that are independent of each other. If a story does impact on previous stories then all the work will be covered by the new story and the estimate will be for the entire impact. Note that velocity is just a measure of what the capacity a team has for getting work done in a sprint.
  5. In Scrum we try to focus on finishing work rather than starting new work. The intention is to get a true measure of progress. If lots of new work is started, but not finished, it is difficult to measure how much time is remaining. The team should be keeping the number of stories in progress to a minimum and trying to get stories finished before starting on new stories. Backlog refinement is important and as a rough guide most Scrum teams spend 10% or more of the time in a sprint preparing for the next sprint.
  • There is a some reality vs how-it's-meant-to-be-played in your answer. 1) Scrum doesn't want you to show anything that has known quality issues. It's unprofessional and gives a wrong impression of the state of the product. 3) It's also the only way to earn back our investment early. Without visible/usable progress, there is only cost. 5) But don't spend too much, 10% is about right, spending too much creates a false sense of security and builds inventory of pre-refined stories slowly getting stale. Commented Oct 26, 2015 at 9:32
  • 1
    In a recent sprint a tester raised an issue about the text not aligning perfectly on the labels on one screen. The Product Owner reviewed the bug and said they did not consider a fix worth the effort. They asked the team to proceed to UAT release. Would you disagree with that approach? Commented Oct 26, 2015 at 18:29

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.