Tweaking Sprint Planning - Clarus Blog
Tweaking Sprint Planning
The first thing I do is to ban the word “should” in the sprint planning. As a tester, I don’t like this word because it creates assumption. Thanks to Murphy’s Law, assumption is almost always wrong. When people start saying “it should just work”, it kills conversation and people stop thinking about the risk.
Second thing I do is to pick on the junior team member. I will ask the team this: "if the junior team member will do most of the work on this User Story, does the estimate still stand?" what normally happens is the junior team member raises their estimate because there is an uncertainty cloud hanging over his head. The senior team member then starts thinking about step-by-step instructions that he will give to the junior team member and evaluating how hard the instructions are.
Most of the time, the above tricks increase your estimation accuracy and will create more and better discussions. This discussion is what I am seeking from these tricks. At the end of the day, it doesn’t really matter if a number is bigger or smaller. This is just estimation and estimation is never going to be accurate!
Trackbacks
-
http://learnpiano.co.nz
by http://learnpiano.co.nz on Tuesday, 30 November 1999Tweaking Sprint Planning - Clarus Blog ...
Comments
Kurt, you are right. Estimations are usually done during backlog grooming and you are absolutely right, the story point is the size of the actual story not the whole solutions.
Are you doing backlog grooming then followed by sprint planning? What we normally have is backlog grooming, sprint planning one and sprint planning two. Our sprint planning is on Monday and our backlog grooming is on mid week. Backlog grooming is to groom what is to come and remember the information we get during backlog grooming might change, therefore, we need to re-estimate the user story. Normally this re-estimation is done during sprint planning one.
In regards to second part of the planning meeting, I agree with you. I discuss “how” things get done and what needs to get done in second part of planning. The only difference is I never commit/forecast anything until I finished my planning part two. This is because software has a lot of unknown unknown. During planning part two, I might discover some new information and my estimate might be way too low/high. I only commit/forecast once I finished sprint planning part two and when we sing the commit song in front of the board.
User story estimation should be based on effort not complexity. Mike Cohn explains it better than I do. http://blog.mountaingoatsoftware.com/its-effort-not-complexity#comments
Jason nailed my point nicely. The whole point of this “tweaks” is to create conversation and change people mindset for a little bit. At the end of the day, estimation is just estimation.
Estimations don’t have to be done in Grooming. As a matter of fact grooming is not even a mandated part of Scrum – it is optional. I agree with you – it is important to have grooming – but equally have seen many teams do estimation in Sprint Planning part one – when they are selecting the stories they are going to work on.
I think what Stanley is trying to say here is that if you are estimating during Sprint Planning part one then it may be useful to get many different perspectives on the size of the story, including those of a junior.
LOOKING FOR SOMETHING?
|
|
Clarus is a values-driven IT consulting firm committed existing in harmony with our social and physical environment. We value being able to control your own destiny, which is why we make microloans to people who really need some help and are less fortunate than us via Kiva. It is a hand up, rather than a hand out and these loans change lives.
|
Hold on a minute, assuming you are talking about Scrum, something doesn't quite add up.
Estimations are usually done during backlog grooming, before it is decided how the solution to the story will be done, and before it is decided who will do it. The size of a user story in story points is supposed to be the size of the actual user story, NOT the amount of effort required to complete a solution. (The amount of effort that the team goes to to develop solutions to user stories is encapsulated in the velocity metric.)
The user story is exactly the same whether the junior or senior dev does it. Its size is completely independent of who does it, and how it is done, so it is not appropriate to change the estimation.
Sure, during backlog grooming the team discusses the story with stakeholders to learn more about WHAT needs to be done. If you are going into technical details, or talking about tasks, or HOW something should be done, then you are doing it wrong. The discussions should only be related to understanding the problem as the customer sees it.
You only need to begin discussing HOW things get done in the second part of the planning meeting. By then you have already counted the card as being doable during this sprint, so it is too late to change the estimate.
The answer to "if the junior team member will do most of the work on this User Story, does the estimate still stand?" is always yes, because it is not the work we are estimating.