Learn Software Development » Sprint

Does a smaller size of Sprint mean more overhead ?

ashish — Tue, 15 Nov 2011 20:17:32 +0000

In the organization where I work, most of the Sprint cycles are 3-4 weeks long. When trying to determine the size of what a Sprint should be, most teams new to Scrum do not have any great planning process on how to determine the size of the Sprint cycle, and decide based on their talking to teams that have actually implemented Scrum. This mostly works out to be 3-4 weeks long for the Sprint cycle.
In some cases, when the teams had started implementing Scrum and had spent some months at this, there was a query from a number of people in the team about why the team was doing a Sprint cycle of 3-4 weeks. If the group was involved in supporting other groups, then would not be it better for the group to go in for a shorter Sprint cycle, and maybe even evaluate a much shorter Sprint cycle, as short as 1 week. At this point, there were a number of positions in support and against the thought of reducing the length of the Sprint cycle.
One of the biggest objections to a reduced Sprint cycle was about the extra overhead that the teams would be subject to. So, consider the various planning meetings that happen, such as the Sprint planning meeting where planning and estimation happens, then the meeting where the demo happens, and also the retrospective discussion. Wouldn’t the team have to do all these meetings even when the length of the Sprint cycle was much shorter, and would they not consume too much time in relation to the overall length of the cycle ? After all, if these meetings end up taking around 2 days overall in the Sprint cycle of 4 weeks, when you have to do them for a much shorter sprint cycle of 1 week, the proportion of total time that will be spent in the Sprint cycle for these meetings will be far higher.
I don’t know what you folks think, but I do believe that this is not a correct supposition. If you are doing a much shorter Sprint cycle, the amount of User Stories you discuss will be lesser, and as a result, the amount of time you spend for these meetings will be much lower, and the same will be true for the demo and the retrospective. In addition, with a much shorter Sprint cycle, you will be end up being able to react to changes much quicker.

Book: Succeeding with Agile: Software Development Using Scrum

Problem – When stakeholders disrupt the prioritized feature list of items for a Scrum team

ashish — Wed, 09 Nov 2011 19:14:50 +0000

When you start working out some of the basic assumptions of how a Scrum team is supposed to work, one of the base assumptions is that the Product Owner sets the priorities of all the features / User Stories for a Sprint. Now, depending upon business needs, this order can even be changed midway during the Sprint (should be avoided in most cases is what most of the literature says) if there are pressing needs to change the priorities. This can also be done by ending the current Sprint at the point where the decision to change the Sprint Backlog is made, and starting a new Sprint (which can be set to end at the same time as the previous length of the Sprint).
However, this becomes a problem in the case of service teams. Consider a team that prepares some kind of infrastructural work for other teams; in this case, the User Stories are derived from the needs of other teams, but controlled by a Product Manager who decides the priority for the requests coming in from other teams. This can be quite problematic, since other teams all have their own priorities, and the Product Owner can have a difficult time just trying to balance the requirements of the other teams. If the team is lucky, the requirements of the other teams can be somewhat similar, which makes the work of the Product Owner easier.
I have also see a case where the Product Owner had a really tough time, having to fend off a number of pushes from the different stakeholders that impact the work. So, the Product Owner decides the User Stories based on some inputs, and sets the Sprint Backlog for the defined interval. The team starts work.
And then the pressure starts. Another team suddenly finds that their external environment has changed, and decide that they need something fairly quickly from the infrastructure team. The team finds that the external stakeholders are applying additional pressure and the pressure in this case can rise to such an extent that the team is forced to change their User Stories midway during the Sprint. Once in a while, a team can endure this and understand this, but if this pressure and change in Sprint features keeps on happening, the team starts questioning their implementation of Scrum and will suffer reduced morale. However, it is not realistic to assume that the Product Owner can easily overcome the external stakeholder pressure.
I do not have a good solution to this one, and did not have one when the ScrumMaster of the team asked for opinions.

How to define tasks for a User Story without spending a fair amount of time on these ?

ashish — Sun, 30 Oct 2011 18:56:46 +0000

We seem to find ourselves running into a fundamental problem during out Sprint planning meetings. Some of it is from our older methods, but partially it also seems to be a problem with the way we are using our Scrum processes. Consider the process before getting into Scrum. We would have a list of features defined and agreed upon by the Engineering and Product Management teams to be done in the defined product development time cycle. However, things were problematic when actually getting into the actual stage of working out the tasks for these features. Many of these features involved features that were not done before, and so it was required that these features be broken down into tasks, and the team leads were assigned to this purpose. It would take a matter of some time for the features to be actually broken down into a matter of tasks. The feature team would need to have a few meetings to discuss the feature, talk to the User Design specialist to understand the way that the feature would work, and then work out the tasks.
However, it would take more time to work out the estimates for the task, and in many cases, this was a matter of guesswork, since the work required for the tasks had never been done before; getting these estimates involved some amount of discussion. And once these estimates were in place, when the actual work was happening, these estimates did change many times (sometimes the User Design was different from the one initially considered, and in many cases, the estimates were actually different from the work that was needed to be done to complete the task). This meant that the total effort needed to complete a feature was different from the estimates; and this happened for many of the features.
Now, when we started using the Scrum process, this became an open question. For many of the major User Stories that were a translation of the major features, getting tasks broken down into the User Stories was a major effort by itself, and it was postulated by the team that earlier it would take so much time to break down the features into tasks, how would it be possible to do this during the Sprint Planning process ? It was somewhat difficult to answer this question, although we did some amount of planning on how to define User Stories in such a manner that they would be readily understandable and could be broken down into discrete tasks that could be estimated with some amount of accuracy. This took some time to actually happen, and there were many cases where the effort estimation did not match the actual effort needed for the tasks.

Scrum – Having to make crucial product decisions, and yet not aware of the overall design of the product

ashish — Wed, 27 Apr 2011 18:48:11 +0000

This is a Scrum story that does not have any easy solutions, and yet we faced these many times. It could be because our working of the Scrum process was imperfect, or could be because of the way that the relationships between the Scrum team and the Product Owner were setup. So, if any of you readers have any comment on what we could do to improve things, do let us know.
The story is around designing a complex product in Scrum. The product has various modules, various dialogs, several workflows, some of them inter-dependent, and others that feed into each other. For such a product, the design complexity in terms of architecture was fairly complicated, and we needed to get a good architect in place to work through the various components. As a result, it was necessary that a certain logic in terms of which component got created at what stage was required, and in a conventional workflow, we would have insisted on getting this design workflow as part of the items that needed to be done.
In the Scrum based system, we had to depend on User Stories written by the Product Owner, and as a result, it was a challenge to get the Product Owner to understand the User Story in the form of a design relationship, as well as the sequence in which these design stories were made and the necessity of getting them. Our Product Owner was a very confident person, and it was difficult sometimes to get the Product Owner to understand that an entire Sprint was to be spent in design steps, and there would not be something that would be delivered in the form of User facing features at the end of the Sprint.
Sometimes the discussion would get very difficult indeed, and it was beyond the power of the Scrum team to convince the Scrum team, and we would need to get more stakeholders involved; but the sponsor of the project was fine since he felt that having such a Product Owner would be like a check on the engineering team, and ensure that only those elements of design was done which were necessary. This was however pretty frustrating for the Scrum team.

Scrum – Can you extend the Sprint duration midway through a Sprint because of some reason

ashish — Tue, 05 Apr 2011 18:56:15 +0000

The Sprint duration is typically a fixed duration, being the same for every such Sprint. Getting a fixed Sprint duration means that the team is able to work out many processes that increase efficiency, allows the Sprint team to develop a rhythm; such fixing of the duration also allows various stakeholders including the ScrumMaster and the Product Owner to evaluate the progress of the team over multiple time periods and figure out improvements in efficiency; and also check out some of the environmental conditions (including morale and team friction) that come into play over a period of time. If for any reason, the Sprint duration gets changed, this can actually shake all these observations; further, if the team sees that the duration of the Sprint can get easily changed, it can shake the confidence of the team in the Sprint, and leaves a certain amount of variability regarding this Sprint duration.
Now, let us see the actual condition in which the Sprint duration may need to be changed. Consider the case where a set of User Stories have been marked for a Sprint and the team had done the proper estimation and set up a series of tasks to be completed during the Sprint. Now consider that the team is doing a series of tasks and finds that one of the tasks is getting delayed due to some impediments (and could even be that the estimation for the task was not proper); the Product Owner considers this task as very important and needs to be ready at some point in the current Sprint even if the Sprint is extended.
So, it comes to this point, where the Product Owner is pushing to extend the Sprint duration so that the important task is completed and can be showcased to clients or to other stakeholders. So, what should be done then ? Well, I talked to some experienced ScrumMasters, and the majority opinion was that the Sprint should not be extended. Due to the problems that I listed above, extending the duration of the Sprint is something that really needs to be avoided. One way to get the important task done earlier is to reorganize the pending work, and some of the pending work can be set aside for the next Sprint and more effort put into the critical task. If not possible, then the work should be moved to the next Sprint where the appropriate amount of effort can be estimated for completion in the next Sprint.