Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Dev Envirnoment Issues and Performance Testing

Last post 08:58 am October 28, 2013 by Prab M
3 replies
10:17 am October 17, 2013

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?


11:11 am October 17, 2013

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 improvement that should certainly include getting work closer to live.

11:22 am October 17, 2013

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.

08:58 am October 28, 2013

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.