Learn Software Development » Sprint

Planning to ensure that the Sprint Planning meetings work well as a part of the Scrum process – Part 2

ashish — Fri, 07 May 2010 17:24:37 +0000

In the previous post (Sprint Planning Meeting – Part 1), I talked about some of the points that people need to take care of during the Sprint Planning, including some of the responsibilities of the Product Owner, calculation of the total available capacity of the team for the Sprint, and then breaking down the user stories into smaller components. In this post, we will talk more about what it takes to make the Sprint Planning meeting successful.
- A lot of teams actually ask the Product Owner to leave when the Sprint team is breaking down the user stories into much smaller tasks that need to be estimates; the reasoning goes that the team would need to break down the features into tasks without any influence from the product owner, but the product owner should be somewhere where he or she can be called quickly for clarifications or other such details.
- Setting a Sprint Goal. A Sprint Goal sets the team a broad target for the overall effort, something that is achievable; even in the case when all the tasks slotted for the Sprint have not been met (this ensures that there is some flexibility in the entire system); what is equally important is that the Goal should not be laid down to the team, instead the team should be involved in the decision making to select the Sprint Goal. There are many advantages of the Sprint Goal such as ensuring that everybody is on the same page with respect to the features, ensure that features working towards the goal are selected for the Sprint, and also ensure that the broad goal can be sent to all the external stakeholders.
- We need to spend some time on the task definition. A task needs to be defined in a way that it is easily testable, feasible, and also fairly small that they can be done in a short period of time (it does not work if you define tasks in a way that they extend for long periods of time). The item needs to be clearly testable with clear parameters set for failures and successes.
- The prioritization needs to happen such that it takes care of dependencies and infrastructure needs. For example, if other teams depend on a task that this Scrum team needs to do, this needs to be factored in the prioritization (even if the importance of the task to the Scrum team is not so important). Similarly, if there are tasks that are needed for design or other infrastructural purposes, then the priority of these also needs to be set properly.
- Set a defined schedule for the meeting that consists of defining the separate items that need to be covered in the meeting, the purposes of each of these items, who will be driving these items, the documents that are generated from these parts, and also the defined time interval of each of these activities. These activities are:
Calculate the capacity for the team
Product Presents the various stories and answers questions
Team breaks down the stories into smaller discrete tasks
Team commits to these stories along with estimates, ready to start.

Scrum of Scrums – a brief definition and some details

ashish — Tue, 02 Mar 2010 16:38:11 +0000

What is a Scrum of Scrums ?

Well, if you take any literature that deals with Scrum, you will find the typical team size for a workable Scrum team to be 7-10 people (ignore those articles where it is claimed that Scrum has been made to work with 50 plus team members, since that is more of an ideal case); what happens when you have a larger team ? Well, that is where a concept called ‘Scrum of Scrums’ comes into being.
A Scrum of Scrums is when you have larger teams, and you divide the teams into smaller Scrum sized teams. Each team does their own Scrum meeting, typically at the same time, and then each team send one representative to a meeting where representatives from each team goes. And if you have many such teams, then you can have a Scrum of Scrum of Scrums (and no, I am not making this up).

Who attends the Scrum of Scrums

Since the Scrum team is facilitated by the ScrumMaster, you would expect the ScrumMaster to attend the Scrum of Scrums meeting. Or in his absence, the Product Owner. Well, the advice is different – a member of the team should attend the Scrum on behalf of the team, and this can be any team member. It follows from the above that since any team member can attend, the member who is attending the Scrum of Scrums can keep on changing after every few meetings. However, it is not a total free for all, sending the person who will be best able to project the current position of the team; such as a tester when the team is in the testing phase; or a designer when the project is in the initial design phase. This also means that the Scrum of Scrums can be attended by the ScrumMaster as well.

Can the team send only one representative ?

No, most emphatically no. It actually depends on the size of the constituent team of the Scrum of Scrums. If there are fewer members in the team, then a team can send 2 representatives rather than one. One of these can be a ScrumMaster.

How often does the Scrum of Scrums need to happen?

A Scrum meeting is supposed to happen daily, so does the Scrum of Scrums need to happen on a daily basis as well. No, there is no such requirement. Depending on how the teamwork happens, and how the Scrum of Scrums becomes more efficient, it is very much possible to restrict the Scrum of Scrums to happen only 2 times a week, or maybe 3. These meetings can be different from the Daily Scrums in one significant way; problems can be brought before this meeting and solutions attempted (which is different from the regular Daily Scrum meeting where impediments can be brought up but not resolved to keep the meeting tight).
Further, these meetings do not try to work through a regular backlog of features and tasks, but instead focus more on coordination and inter-team dependencies and relationships.

Ad:

How to decide the length of a Sprint cycle – Part of Scrum

ashish — Fri, 12 Feb 2010 05:29:28 +0000

When you decide on using Scrum for your project development needs, one of the important questions is about the length of the Scrum cycle to be used. Not an easy decision in any way for the team, and something that the ScrumMaster has an important role in deciding. One thing to keep in mind is – the official length of a Sprint cycle is 30 days, but it is done as per the needs of the team. Here are some of the factors to keep in mind while discussing the length of the Sprint cycle:
- Planning and meeting time: Every Sprint cycle needs the following set of meetings, Sprint Planning, Sprint Review (including demo), and Sprint Introspection. As long as you can ensure that by reducing the time of the Sprint cycle, these meetings do not end up taking a larger percentage of the Sprint cycle, you are fine with reducing the time period of the Sprint Cycle.
- Ability to break down the requirements: The Sprint team executes on the user stories generated by the team. If the Product Owner cannot reduce the user stories into discrete enough levels that the team can execute in the shorter Sprint Cycles, then maybe the team is not ready yet to move to shorter Sprint Cycles.
- Eventually the Sprint cycle that needs to be adopted is the one that works the best for the team. Imposing a cycle that makes the team under too much pressure or does not have enough pressure needs to watched and then the best one implemented. A team that is mature will be able to do shorter Sprint cycles with much greater ease.
- When the team is working on a product where there is a need to move quickly, such as a team that needs to release patches, or new features for a web product (based on competitor analysis), then having a shorter Sprint cycle works much easier. Having a Sprint cycle that is a month or more could mean missing out against competitors.
- Having a shorter release means that the team can measure its performance far easier as compared to longer Sprint cycles where the performance can only be measured after a period of time in which it is too late to make corrections. This is problematic if the final release is only 2-3 months away.

What is a good time duration for a Sprint in Scrum ? 30 days ? 2 weeks ?

ashish — Mon, 08 Feb 2010 20:12:50 +0000

Asking the above question is like entering a tricky arena. You just cannot make a good answer unless you know more about the environmental situation in which the project is being run. There are plus and minus points to having a shorter Sprint. For example, having a shorter Sprint leads to:
- More time spent in Sprint Planning, Review and Demo for the Sprint Cycle. After all, if you have a week or 2 week Sprint cycle, there is a perception that you may be spending a larger portion of that time in terms of these meetings
- A longer Sprint means that the team has enough time to do those complicated design and architectural changes and not run them through, as could happen when you have a shorter Sprint cycle (although Sprint experts would believe that the Sprint cycle duration should not change anything related to effectively completing even complicated tasks)
- A shorter Sprint cycle means that you are able to see the end results of your work in a shorter time-frame, and there is less Work in Progress.
- A shorter Sprint cycle means that Product Owners and stakeholders are able to view the work happening on the product (via demos) at a much more frequent time-frame
- Having a shorter process also brings some strains into the system, and if you are looking at making improvements, then such strains can point out areas that need improvements

There are points for both sides. The more important question is about whether a team is looking at implementing Scrum for the first time, and is looking at defining a proper time pattern for the same. On the other hand, if a team has been already implementing Scrum and finds some issues about the length of the Sprint cycle that they are following, then it is more important to analyze as to why the team is finding problems in making its existing Sprint cycle work. That is more important in figuring out, since there might be some problems in their implementation of the Scrum process.
For a new team, it is easier to start out with a 30 day process, since that gives them the time to settle into the Scrum process; over a period of time as the team becomes more comfortable, they can be moved to a shorter, like 2 week, Sprint cycle and by that time, they will also be ready for a much shorter Sprint cycle.

Participants in the Sprint Planning Meeting – An integral part of Scrum

ashish — Sun, 17 Jan 2010 17:39:42 +0000

We have described the Sprint Planning Meeting in earlier posts; a brief about this Sprint Planning Meeting: A meeting where all the Sprint team works through the Product Backlog and describes the features that need to be implemented in the current Sprint cycle.
This post will work through more details in the Sprint Planning Meeting including the role of each of the participants.
The different people who need to attend the Sprint Planning meeting are the following – Product Owner, Scrum Master, the Scrum Team, and any stakeholders such as management, customers, etc.
What do each of these key stakeholders do ?
First, the important role is that of the Product Owner. The Product Owner details the various items on the Product Backlog, and specifically focuses on the highest priority features of the team. For these items, the Product Owner needs to be responsible for answering all and any of the questions that the Scrum team has that they need to determine the effort estimation for the features. However, the idea being that the Product Owner should not have to detail all the features on the Product Backlog, only focus on the more important features.
The Scrum team is responsible for ensuring that they get all the details they require for being able to generate the task break up for the features, and also be able to accurately estimate the effort required for such tasks. In the beginning, the team may not be able to make accurate estimates, but over a period of time, the team will get better at being able to ask all the right questions and estimate the effort.
The Scrum Master has to ensure that this process is happening, running the meeting and keeping it moving along. The goals for the meeting need to be achieved, without the meeting going into heavy extra-time.
During the meeting, the team (including the Product Owner) need to establish the goal of defining the Sprint goal, an overall description of what the Sprint is supposed to achieve (and this helps in making sure that the team has an overall goal) and which will be measured at the Sprint Review meeting.