Forums

By posting to our forums you are agreeing to the Forum terms of use.
Dev Envirnoment Issues and Performance Testing
Last Post 28 Oct 2013 07:58 AM by Prabhu Missier. 3 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Tom Hosiawa
New Member
New Member
Posts:1
Tom Hosiawa

--
17 Oct 2013 09:17 AM
    Hi, I have two questions in trying to apply scrum to our organization

    1. We have issues with our development and/or testing environments being down (from a few hours, to a days in two week periods ). How do you account for these in the sprint when they occur? If you lose a day of development, should you remove an item from the sprint backlog?

    2. Because multiple projects are competing for access to our performance testing environment, they must be schedule way ahead of time, meaning we can't incorporate it in our DoD definition. Any thoughts on how to best approach this?

    Thanks
    Tom
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    17 Oct 2013 10:11 AM
    1. Assuming that there is no other work on the Sprint Backlog that can be progressed, and that the Sprint Goal is likely to be affected, the Product Owner must be notified. The Sprint needs to be replanned and this could indeed mean changing the backlog. In an extreme case the PO can terminate the Sprint if the revised ROI does not justify continuing. In terms of replanning, the Scrum Team should give priority to overcoming the environmental issues since that is part of their process, and they are clearly not in control of it.

    2. You have a problem in so far as you will accumulate technical debt in relation to system performance. It also implies that each end-of-sprint increment will not be potentially releasable into live, and that ROI and further discovery will be delayed. Unfortunately, again it shows that the team are not in control of the process for creating a potentially releasable increment. This can be tackled gradually, such as through better release planning that expressly includes performance testing. Note that the Definition of Done can (and should) be improved on a Sprint by Sprint basis...an improvement that should certainly include getting work closer to live.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    17 Oct 2013 10:22 AM
    NB transparency is key in both matters. Cumulative Flow Diagrams should reveal the blockage of work due to system downtime, and its accumulation prior to entry into performance test. This information should be shared with stakeholders and influencers. They might be in a position to supply better resources if the impact of the current set-up is made clear in this way.
    Prabhu Missier
    New Member
    New Member
    Posts:26
    Prabhu Missier

    --
    28 Oct 2013 07:58 AM
    1)Looks like a candidate for a recurrent impediment. If it happens unpredictably then you would need to adjust your Sprint Backlog and Sprint goal accordingly.
    But if you can predict it then your Sprint Plan needs to handle it. If you have previous data then you might have a fair idea of the amount of work you can accomplish inspite of the impediment. That being the case your Sprint planning will have to factor in the predicted disruption and forecast a reasonable Sprint goal.

    Ofcourse it is the duty of the Scrum Master to remove impediments so he or she has to make an all out effort by even talking to C level to isolate and solve the problem.

    2)I am facing that issue right now. My Perf team has gone on vacation and there's a lot of pressure to dilute the Def of Done and not place emphasis on Perf testing.
    I for my part have said that this is unacceptable and have approached Senior Management for their help since it is quite obvious that a properly "done" story will include Perf testing as well if it is relevant at all to the story.
    You are not authorized to post a reply.


    Feedback