Learn Software Development » Estimation

What to do when priority of your requirements changes in the middle of the cycle ?

ashish — Thu, 13 Oct 2011 18:15:53 +0000

One of the questions that I saw recently coming up during a recent discussion was about what happens when you need to change your requirements during the middle of a Sprint cycle. This was a team that had set Sprint cycles of 30 days duration, and normally never had an issue with any modifications required during the Sprint cycle.
Typically, the Product Owner would define the list of features that are needed, puts them into a priority (and this would include infrastructural and design tasks that are stated by the team as well), and these are entered into the Product Backlog. Then, in the planning meetings, the team would work through the prioritized items, estimate the features and tasks that are likely for the current Sprint, and come to an agreement of which are the tasks that would make it for the current Sprint. Then it is a question of tracking the tasks through the Daily Scrum meetings and taking it through till the end of the current Sprint.
The twist in the tale comes if you need to modify the items in the Sprint. For example, suppose you have a list of items ready to proceed with and midway through the Sprint, the customer comes back and states that a very important feature has suddenly cropped up (needed for some business purposes), and hence it needs to be done for the Sprint. Now, this very question was asked by a team member when a situation arose where we needed to make such a change. Given that Scrum training can depend on the person giving the training, one of the people providing the training told the team that it is possible to modify the list of features during a Sprint cycle, as long as the Product Owner provides an updated prioritization of items. So, the list of features to be done in the Sprint could be different from what was initially decided.
However, this seemed a bit odd, since all the material that I had read till now seems to indicate that once a Sprint is started, you should not modify the list of features. It is also not easy, since any change has a significant impact on the ongoing Sprint, you have not given the team a chance to do an estimation of the changes. What is more likely (as I found from many articles on the subject) was that if the matter is so urgent, then the current Sprint should be curtailed as it is. A new Sprint should be setup where the new priority of features should be setup, estimated, and if necessary, the duration of the Sprint should be curtailed so that it matches the desired delivery date of the features. However, all this will have an impact on the productivity of the team, but if the importance of the required feature is so high, then this change will need to happen.

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

ashish — Mon, 20 Dec 2010 19:08:30 +0000

I have been writing a series of posts that talk about how to improve the Velocity of a Scrum team, through getting rid of various items that can reduce the Velocity of the team, as well as steps that can improve the efficiency of the team (How to improve the Velocity of the scrum team). In this post, I talk about some of the dependencies that can cause problems in the efficiency of a team, along with examples of how the efficiency gets reduced.
We were working on a product which used some components provided by an external third party, and these were integral components. We could not avoid using these components since they provided us a functionality that was required for our product to work, and we did not have the time or the budget to produce these components ourselves (and it would not have made sense since we did not want to get into the business of assigning resources and supporting the functionality that this component provides).
However, we did know that we had a dependency and which could have some impact on our product schedules. We planned for tasks that entailed incorporating the component, dedicated the required amount of time and effort to integrate and fix any integration related bugs, and so on. Further, we had some team members who had experience in this area, and asked them to work through the required estimates for these tasks.
So, we were all set, and believed that integration this component would be a breeze. However, when we integrated this component, there seemed to be a problem. We usually would get a few bugs that were related to integration and some impact on our product, but in this case, there seemed to be a major problem. The integration resulted in a product that was far more shaky, and as a result, we had a lot more bugs suddenly found that seemed to be much more than what was normal. The tasks related to integration of the component took far more time, since there needed to be a large amount of time being spent on investigation and coordination with the vendor, and of course, the resultant bugs that were far more numerous.
It took us 2 more people dedicated to an extra week just to do another integration of the component after the bug fixes, and this had an incredible effect, since with a 6 member team, a large amount of work that was planned for that Sprint did not get completed, and this led to an unhappy Product Owner and senior management. The only solace for us was, that due to this impact, we were able to generate sufficient pressure to force the vendor to adopt a more thorough QE cycle; but for us, the amount of Story Points completed in this cycle were far less than what we had expected; this also set the ground for a far more interesting and detailed retrospective.

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

ashish — Wed, 15 Dec 2010 17:43:12 +0000

I have been writing in a series of posts about issues that can impact the Velocity of the team (Velocity of team), and I will write in more detail about some more items that can affect the Velocity of the team.
- Lack of technical expertise in the team. This is a common problem that can affect many projects. When organizations take on some projects, there is some inertia to looking outside the already present team members for forming the team. So, when a new feature has to be implemented that requires some technical expertise not present in the team, it can disturb all the calculations around team efficiency and velocity, and those are not even accounted for when the estimates are done (it is only very capable teams that do the calculation regarding time taken for ramping up technically, or for hiring new people). Consider a case where a product development team was working on a C++ based application, and then needed to work towards some integration with online based products. For this, the team needed to work on a Flash based application that would be the integration between the desktop and browser environments, and team members really did not have expertise or experience in developing Flash based applications.
The team had constraints in terms of being able to bring in new team members midway during the product cycle, and although some effort was made to provide training, it was obviously not enough. We realized that we had to increase the amount of time required for the task, and this naturally impacted the overall work that the delivered (the estimate provided by team members was like that which was provided by an inexperienced team, and was not really realistic enough). A further problem was that because the team was so inexperienced with the usage of Flash for creating applications, the quality of work output was much lower that expected. This in turn led to a greater emphasis of QE for these applications, with more bugs generated, and this had a ripple effect (more bugs generated, more time needed for bug fixing, and multiple iterations needed for these rounds of bug fixing and bug testing before we could be satisfied that the applications generated were of high enough quality).
What should we have done instead ? It is a difficult question, since it is not realistically easy enough to be able to hire the people of different technical expertise as and when needed; however, the consensus opinion of multiple Scrum Masters was that somewhere we need to account for the fact that this is a new technical area and the amount of time required would be more. In that sense, there would need to be added relevant User Stories that account for training, and also to include tasks that cover the additional testing and time required. This may lead to a situation whereby the actual output is lower than what many other stakeholders can expect, but I would suggest that this is the best possible course possible.

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

ashish — Thu, 02 Dec 2010 18:28:39 +0000

In the previous post, we talked about about the dependencies and design issues (improving the Velocity of your Scrum team) that can impact the efficiency of the Scrum team and how to monitor them to improve them. In this post, we will talk about these and some more factors that need to be monitored to improve the efficiency of the Scrum team.
- In the previous post, I had talked about the dependencies that come out of the dependencies between the teams. I wanted to talk more about such dependencies and the complications that can come out of such dependencies. Consider the case of multiple teams that have complex dependencies between each other and which follow the Scrum model.
So, consider the case of a team that depends on another team for some components. Both these teams follow the Scrum model of development, and plan for each Sprint at a time. This is something that I experienced when we working for a project. We had talked to another team for some components in advance of when we needed these components for a future Sprint feature. However, given that the other team was also doing a Sprint planning, these requests went into their own Sprint planning backlog for prioritization by their Product Owner.
The other team was a supplier of components to many product teams, and as a result, our request was balanced against their other priorities and was not considered important enough for the current backlog. Further, since the team only did selection of tasks for the forthcoming Sprint, it was hard for them to commit as to when they would be able to support our needs. And, given that our request was a bit complicated and different from their other requests (from other teams), they were unable to do an easy estimation of the time that would be required to implement unless the request went through the whole process of Sprint Planning, explanation, and estimation of the tasks that went into doing the User Story.
So, the net result was that we we had a feature that was fairly important for our product, but in the overall scale of importance for the organization, there were other teams that were more important and hence we did not have a commitment for when the dependencies would be resolved. And the problem was, this was as per the Scrum process. So, what was the solution. One way would be for the other team to be able to spend the required amount of time of analysis and commit in advance of the Sprint (by tasking a User Story for the breakdown of the request and estimation) and, further, do some scheduling of these User Stories for the forthcoming Sprint outside of the regular cycle of Sprint planning.
And this was exactly what we did, through working with the Product Owner and other managers of the team, and seemed to realize that this was not a good way of resolving the dependency, but we really did not have a good solution. If somebody has some better ways of working out such dependencies, then please do put these in the comments.

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

ashish — Tue, 30 Nov 2010 19:18:19 +0000

I have been covering a series of posts on the topic of how to improve the Velocity of the Scrum team (how to improve the Velocity of the Scrum team). In this post, I will continue on the same line and mention some more points that can help in increasing the effectiveness of the Scrum team:
- Make sure that design issues are resolved promptly. For Scrum teams who work on simpler projects, there may not be a lot of complexities in terms of architecture, but for teams where the architecture is complicated, one does need to think ahead. Even though the Scrum model talks in terms of breaking up the tasks during the Sprint Planning session and doing estimation, there is the need to work through the design and architecture issues beforehand. For complex Client Server application (such as where you would normally have made complicated designs to depict the architecture of the system), the need for proper design does not go away just because you are using Scrum. Make sure that enough effort and thought goes into doing the proper design and architecture for building such complex applications. Combine this with the proper sequencing of such tasks as a part of your Backlog such that the design of such tasks happens in the desired sequence. You may also need to ensure that there are enough experienced people to oversee the design process (else you would find that you start running into cases where for lack of enough effort, design issues start to hit people and the tasks that the team has to do take more time, or there is waiting required).
- Make sure that there is enough time and effort being spent on planning for dependencies. When a product is being built, there are a large number of dependencies that could go towards delaying the various tasks inside the product development cycle (for example, there could be software being developed by vendors, or a new version of a Browser / Operating System that could affect your product, or the ability to get some of the features taken through a user review process where the inputs from such a review could cause changes in the product (small incremental changes or product rework)). These have the potential to have a huge impact on the product cycle (in terms of wreaking havoc on the product cycle) unless there is intense planning and scheduling of such tasks. For example, if a critical piece of technology from an external vendor is required in order for some tasks to get completed, and then the technology is of poor quality or gets delayed, it can have a cascading effect on the various tasks that follow. Hence, there needs to a very look at such dependencies and have contingencies plans ready to take care of different situations.