Agile - Running Successful Sprints
In an agile work place sprint success is an important factor that can give interesting observable outputs. These outputs can be: how motivated the team is, how is the team's morale, how reliable is the team.
What is a successful sprint? Well, a successfully sprint is a sprint were all the work planned at the beginning of the sprint respects the Definition Of Done which you or your company compiled.
Sprint success is an important factor from my point of view. It is an important criterion that denotes if your future planned work will be delivered or not. Having a team with a steady velocity creates stability for you as a Project Manager if there is one or as a Product Owner, it gives you the possibility to make commitments to the clients without making a fool out of yourself. Sprint success is also an important factor when it comes to morale as this can affect the team in the long run.
Fudging the numbers once in a while can help the team in a moment of need, but doing it on a daily basis can lead to unwanted behavior, basically you are covering up what is happening, the problem and even the root of the problem.
Descoping items from a sprint so that the burndown looks OK, should be done when the team is in a beginning stage where they are still learning how to be agile and work in sprints, if you find yourself doing this more than 70% of the sprints you are running, then you need to adapt (again I am not talking about exceptions).
How can we do to drive a successful sprint?
Simple, agile is an empiric system and all you need to do is experiment, observe, adapt. First you must pick a storypoint limit for your team. A useful way to do so is by using the PERT technique (https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique). Get some data from history and see how the team handled the old sprints. Prepare numbers for a pessimistic velocity, and optimistic one and a "most likely" one. With this data gathered, the PERT technique is pretty straight forward, the velocity should be (optimisticVelocity + 4*mostlikelyVelocity + pessimisticVelocity) / 6. Let’s do a simple example, we are looking at a team that usually delivers ~65 story points this is the most likely one, and we observed that they managed to deliver a couple of times 80 story points, this is the optimistic one, and we also had some sprints that ended with ~30 story points, making this the pessimistic velocity. With this data, the value we should go with as a start is (80+4*65+30)/6 = 61.6, we round it up to 60 and that should be a good start.
Some of you might use working hours as a break down for the subtasks, while this is a semi-important step in a migration from a Waterfall to an Agile environment I noticed that there is always extra work found after the task starts. The simple solution is to first get some bearings and get to a point where you have reference data. This reference data should be stories that you can distribute for every story point card you have in your planning poker deck of cards. If you are using the Fibonacci series (as an example) then you would have: 0,1,2,3,5,8,13,21,34,55,89. You should have a story for each estimate that you can consult when giving estimates for the new ones. After you have compiled this you can estimate stories. Most of the time the estimate of the story is more accurate than the working hours break down. With that in mind try and limit the items you take into a sprint by story points rather than by the working hours capacity for a team.
If you pull this off, then congratulations you now are one step closer to begin Agile.
You might fail once or twice or even more, but you are on the right path, experiment a bit with it and all should be fine.
