According to the scum theory, the developers should decide during planning meeting 1 which features they can implement during the next sprint. So for each new user story they should decide whether there is enough time left to implement it. This procedure should give the developers the chance to do a truly commitment.

But what is the basis for this decision. Should the development team estimation the effort and compare it with the given sprint time frame? Or should they simply trust their feelings?

Furthermore the user stories are already estimated. No matter what estimation type u use, story points, feature size or man days, you will do the effort estimation within the product backlog. So why don’t u use this estimation during the planning meeting? Why should the team decide once more about the effort? Because otherwise the sprint user stories are given by the product owner and so the development team is externally controlled and can never truly commit to the sprint goals.

In addition there is another issue. By using a fixed time frame for the sprint and a fixed set of features which should be implemented, you will violate the economical principle. It is not possible to reach both goals, the fixed sprint finish date and the fixed set of user stories, because these are contradictory goals. According to the economical principle you should choose one of these goals and try to maximize or minimize the other one. So you should maximize you feature output in a given time frame or minimize the time needed for a fixed feature set.

In summary, I think, it is not useful to do direct or indirect time estimation during planning meeting 1. One might even say it is unfair to call for a commitment of the team. Why? Because you set up a fixed time frame – which is very easy – and want your team to define the contradictory goal of the sprint content – which is impossible as long as you respect the economical principle.

But can we find a way out of this blind alley? What if we do the planning meeting without time estimation? I think that’s also not useful because then the product owner does not know what he might expect at the end of the sprint and the development team will start the work without a commitment.

I think the team must do a time estimation to commit their self to each user story. But this should not be done during the planning meeting. This should be done in a prior estimation meeting where all new user stories will be evaluated. And these estimations should be used during the planning meeting. Only if the team gets some new information during the meeting which influences the total effort, a new evaluation should be done. By doing so it is possible to avoid any pressure to do a commitment during the planning meeting. The commitment was given previously for each single user story. This might sound a little bit like the issue is only transferred to another meeting. But this is very helpful because this user story estimation meeting will give the perfect frame to do this estimation. In contrast the planning meeting ha another goal and therefore effort estimations during this meeting will have a lower quality.

During the planning meeting 1 you will use the estimations previously done and documented in the product backlog. You can now sum up the effort of all selected user stories of the sprint and compare it with the personnel planning. So the first issue is removed but there was another issue: follow the economical principle. So if you use a fixed time frame for the sprint you are not allowed to just sum up the effort of all user stories and also define a fixed set of features you want to implement in the sprint. Of course you have to define the content of the sprint, but with a planned variance.

For example during the planning meeting 1 you may define user stories with a total effort which is higher than the available time of the sprint. For example you may define 20% more user stories. Additional the product owner will prioritize the features of the sprint. So the development team can start with a defined list of must have features, should have features and nice to haves. Now they will work according to the maximum principle and will try to implement as much as possible features during the given time frame of the sprint.

At least it can be discussed whether this procedure will improve or worsen the team commitment to the sprint. I think with a vague time estimation during planning meeting 1 combined with an unrealistic goal of fixed time lines and fixed feature you will only get a forced and therefore dishonest commitment. On the other hand with the prepared time estimation and a prioritized feature list you will only get a vague commitment. Maybe you try some different strategies in your sprints because there is no best solution. It always depends on your development team, on the project conditions and on the general conditions whether one way or the other one is more efficient.