Search this site
What is a good time duration for a Sprint in Scrum ? 30 days ? 2 weeks ?
Filed Under Scrum, Sprint | Posted on February 8, 2010
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.
Scrum – More details about the Planning Poker process
Filed Under Scrum | Posted on February 6, 2010
The previous post (link) gave a brief introduction about what Planning Poker is, and what is the relevance to Scrum. This post has a bit more detail on the same subject, including conditions in which the Planning Poker is used, some of the related terms, and so on.
The Planning Poker needs to happen as a part of the Sprint Planning, after you and the team have had a chance to go through the various queries on breaking down the features into tasks, as well as deriving the Sprint Backlog from the features contained in the Product Backlog. The Sprint Planning has a defined time-period, and the use of Planning Poker to generate estimates has a defined time period that is part of the overall Sprint Planning meeting. You need to ensure that the team sticks to these time lines, and does not go very detailed discussions about these estimates, whether the estimate entered by somebody is right or wrong.
Also, since the Planning Poker is a part about the effort estimation process, make sure that the Product Owner is there, and if not, then set the discussion to happen at a time when the Product Owner is there.
Make sure that you have researched the process before proceeding on this one (including using the Fibonacci scheme to generate the alternate feature estimates – the Fibonacci scheme is one where the previous two numbers when added together, make the next number, the sequence goes like this – 0, 1, 1, 2, 3, 5, 8, 13, 21 etc).
Set rules for how the Planning Poker process should operate. If external stakeholders start interfering with the estimate selection process, then we have a problem on hands in terms of not letting the team be empowered to be able to estimate, and they will start getting accurate over these results as we do the review sessions.
Set rules for which estimates will be selected. So, if you consider the Fibonacci sequence above, people may be able to estimate for other 5,8 or 13 hours for most tasks. So, since you have a shortage of time, and you consider the first reaction of the team for providing these estimates as a good relation to their gut feel, you should specify which of these estimates should be considered. If somebody put a 5, and somebody did a 8, you should be able to set policies in the beginning about which one of them would automatically be selected. And the fact that people are expected to not know what the other persons are predicting in terms of effort numbers is actually a plus, and it is only when the different people open their cards do they get to know what other people are projecting in terms of effort.
Why do you need to be more strict in such kinds of estimation, and the time periods required by which this meeting would conclude.
The first estimates that a person prepares is typically a fair idea of estimate, and one should ensure that a lot of time is not spent on verifying and cross-resolving the individual estimates, just make a rule about which one to use, and go ahead.
Planning Poker and Scrum – a brief introduction
Filed Under Estimation, Features, Scrum | Posted on February 4, 2010
First a question. How many of you have heard of something called Planning Poker ? Not too many of you ? Well, that’s okay; in this and the next couple of posts, you will learn a lot more about what Planning Poker is, what it is used for, and so on.
One of the most difficult parts in the Scrum model of development is to estimate the amount of effort needed to do the various tasks that are listed out in the Sprint Planning meeting. If this effort estimation is not accurate, at the time of the Demo at the end of the Sprint, the team would not have been able to complete all the items that the team sought to do in the Sprint Cycle. One of the techniques used for effort estimation during Scrum is called Planning Poker, where people use different cards representing hours of effort and bid for tasks.
Planning Poker is used as a means to let people come up with their estimation at the stage of Sprint Planning when estimation of efforts for the tasks needs to happen (and will happen after the features or user stories have been broken down into smaller discrete tasks). Once all the tasks have been listed, each task is pulled up, and discussions happen on the details for each task. Once the discussion has concluded, people need to put up an actual card up on their own; with different cards being displayed (representing different hours of effort). If it turns out that the cards converge to a similar kind of estimate, then that estimate is recorded; however, many times there is a variations in the estimates put by different people, and then some discussions needs to happen as to why different people give different estimates. Once this discussion is completed, another round of estimation is done, and final estimates are recorded.
Scrum Tool: AgileBuddy (information along with reviews)
Filed Under Scrum, Tools | Posted on February 3, 2010
In the quest to find good tools for Scrum (and when doing Scrum for the first time with a new team), it can be a difficult experience just finding the tool that will give you the least tool-side problems while implementing Scrum. As a part of this, I keep on hunting for new tools that make the Scrum process slightly easier, and search for reviews that other people have written on the same subject. Here is some information from the company site (link) as well user reviews:
Agilebuddy is next generation Scrum project management software that lets you easily Create, Estimate, Plan and Track your software projects. Agilebuddy’s comprehensive set of Scrum tools help teams naturally transition from the traditional waterfall model to Agile software development. Read more about the feature set at this link.
Read more from the following posts:
Scrum and TDD use for Creating Agilebuddy (link)
Borisgloger.com (link)
userstories.com (link)
For self-help, look at the following videos on Youtube (link)
