In our earlier post How to Do Project Estimates In Scrum – Estimation for Fixed Price Projects we had looked at estimation for fixed price projects. In this post we look at some practical issues while estimating and providing an upfront commitment on the scope of the project but there isn’t enough info to estimate for the projects ( which is in most cases!).
While doing an estimates and commit to the number of sprints it would take to delivery a defined scope, all it boils down is to estimate the velocity. Two common problem we face while estimation of velocity is that (1) There is no velocity data for the team (2) There is no team in place yet ( the project is probably in the proposal stage)
(1) There is no velocity data for the team
Let’s assume you have the team but don’t have any velocity data to estimate. Here are the steps you should be following:
1. Have them estimate for stories in story points the normal way for all the stories in the defined scope. Do this even if the team has no idea what their velocity will be.
2, Calculate the sum of the story points for all the stories, lets say 500 points.
3. Now have the team plan a sprint.
This is done by starting with one story, split it into tasks, estimate the tasks in hours and ask the team if they can commit to finishing it. Then repeat with additional user stories until the sprint is full.
4. Assume the team does this and commits to stories A, B and C.Now you have points on all the stories including A, B and C say 18.
5. Add the points on those three stories and that’s a starting point for velocity.
6. You can get the team to repeat by planning another sprint and commit to Stories W, X, Y and Z, which is probably a different number of points say 22.
7. Now you have two values as a range. Say 18 points ( for stories A,B and C) to 22 points ( for stories W,X,Y and Z).
8. Take the velocity by adjusting based on your intuition. If you think the team is about to over commit in their early sprints, use the velocity value at the lower range of estimates i.e 18.
9. Number of sprints to deliver the defined scope = sum of story points i.e 500 / lower range of velocity i.e 18 = about 28 sprints.
10 Add about 10% buffer and round it off to 31 sprints
(2) There is no team in place yet
Let us consider a situation where you don’t even have the team yet and obviously no velocity data. You’ve got plenty of employees in the pool but you don’t know who will do this project.
1. In this case, first workout the profile of the project team like the number of junior programmers, senior engineers , lead engineers etc.
2. Now get some representative people together from the pool, similar to the team profile you have worked out
3. Have the representative team pretend to be the team that will be working and do the same steps “There is no velocity data for the team”
The buffer can be added based on your intuition. A more accurate way would be to take velocity date from other teams, calculate the relative standard deviation ( i.e standard deviation in percentages )
Average those relative standard deviations over all teams and use the percentage as a buffer for the new team.
So, now know have the get the baseline plan/schedule i.e the number of sprints to deliver a defined scope even if you don’t have the velocity data or the team in place.
In traditional Waterfall model testing happens after the development phase just before the release. Agile is iterative and incremental in nature and the testers test each increment of coding as soon as it is finished. Agile testing brings in a number of advantages over traditional testing methods and below are eight key advantages:
1. Incremental Testing
In the traditional waterfall model testing is one phase of the project and tester write test cases based on the requirement specification. Whereas in Agile testing, tester are integral part of the agile team who will test each increment of code as soon as the coding is finished.
2. Discover bugs early
First of all, Agile helps in build, test and deploy faster. In traditional waterfall method, testing is done very late just before the release, where as in Agile testing, the testing is done at early phase (every sprint) which help in discovering bugs earlier and helps to deliver early and good quality.
3. Eliminates big-Bang integration and testing
In waterfall model, code is combined and checked in at large quantity which adds complexity. Where as in Agile, code is frequently checked in and tests are done as and when code is checked in. It helps in providing developers instant feedback.
4. Collaborate and improve quality of software
In Agile Testing, testers collaborate with the programmers and help them improve the code quality by testing where as in Waterfall, testers work in silos and loose the benefit of collaboration. Testers might pair with other developers to automate and execute test cases as coding on each story proceeds. In waterfall, the typical mindset of a programmer is that QA would discover the bugs where as in Agile, programmers work with the testers and improve the software together.
5. Exploratory testing, a new way of testing
Exploratory testing is testing the code in ways developers hadn’t originally anticipated or visualized. Exploratory testing is a style of testing that emphasizes the freedom and responsibility of the individual tester to continually optimize the value of his/her work by doing parallel activities such as learning, test design, test execution, and test result interpretation throughout the project. Exploratory testing is not a test technique on its own. Instead, it’s an approach or a mindset that can be applied to any test technique. Exploratory and scripted testing are at the opposite poles of a spectrum. At the extreme end of the scripted mind-set, the decision as to what to do next comes exclusively from someone else, at some point in the past.
In the exploratory mind-set, the decision to continue on the same line of inquiry or to choose a new path comes entirely from the individual tester, in the moment in which the activity occurs. The result of the last test strongly informs the tester’s choice for the next test.
6. Whole team approach
One of the biggest differences in agile versus traditional is the agile “whole-team” approach. With agile, it’s not only the testers or a quality assurance team who feel responsible for quality. They don’t think of “departments,” and just think of the skills and resources that are need to deliver the best possible product.
7. Automated tests
Agile testing emphasizes on automated testing. Builds are done automatically as and when code is checked in and test scripts are run automatically for each build. Reports are generated and code is deployed/ packaged automatically.
8. Cross functional team
In Agile testing, the Agile team is a cross-fictional team, a group of people working towards a common goal, i.e delivering a quality product. Quality and testing is not just QA team’s goal as in traditional testing.
keep looking »