My team and I are struggling with the what and how meetings. It's hard for us to choose what to work on when we don't know how it is going to be done. Our estimations may be way off when pointing an estimated level of effort.
At this point it's being discussed if we should do the how before the what so that pbi's will be at least reasonably well estimated.
What are some other options that don't require changing the order of the accepted scrum practices?
Teams often struggle to change over from estimating based on detailed specifications to estimating based on light weight User Stories. There is comfort in the level of detail. Consequently they tend to spend a lot of time focusing on the What/How of the User Story and do not feel comfortable making estimates.
The process that I have seen teams move to with success is as follows:
Grooming meeting (prior to Planning) Time box the discussion and planning poker for each User Story to between 10 to 20 minutes; depending on the complexity of the User Story. This requires a Leap of Faith from the team and needs to be back up with a Safe to Fail environment.
In Sprint Planning Part 1 Use commitment based planning to work out which User Stories the team can commit to in the sprint. This is a second Leap of Faith. At the end the Planning Part 1 the team informs the Product Owner of what they think they can accomplish this sprint. However they reserve the right to discuss this again after the results of Planning Part 2. Once used to this process Part 1 should take less then 30 minutes.
In Spring Planning Part 2 All of the User Stories are discussed further and split into tasks. A little bit of high level design / what are we building discussion can occur here. Each task is estimated in hours.
The team now totals up the estimated hours and compared that to how many working hours they have in the sprint. This comparison acts as a guide. If the team feels that they have over committed themselves, the Scrum Master can immediately go and discuss this with the Product Owner and de-scope User Stories from the sprint as appropriate.
Overall I have seen that this process gives the teams a good balance of knowing what they are doing and taking appropriate risks. Good luck
IMHO, what is not "what to work on", rather it is "what need to be done". You need to identify the "what's" before you can determine the "how's". Once that is complete you need to set a mark in the sand for your next release, and use the scrum plan to determine feature compatiblities that will fit within that timeframe, moving on from there the tool(s) should help you identify and better manage slippage.
Do you simply not know what you're trying to accomplish? How can you decide how to do something without knowing what it is that you're trying to achieve?
In my world, we define our tasks by what the end result of the work is, i.e. what is user visible. We do not normally define tasks with implementation details (although sometimes fixes or refactors will mention them). We don't really discuss how we're going to do it, we just say what we did yesterday (that was user visible), what we're working on today (that will be user visible), and identify anything that's holding us up (that is visible to the individual being blocked). Sometimes we'll elaborate with a few implementation details as they can be interesting to team members (e.g. yesterday I was struggling with bugs in our memory manager), but strictly speaking that's not what I got done, that's an excuse for why I didn't get more done.
Estimations may be way off, especially when just getting started. The more estimates you do, and the more you look at estimated time vs. actual time (e.g. by tracking velocity), the better your estimates will get. On our team we have pretty consistently hit a velocity of 50%, so for our two week sprints we schedule 40 hours of work for each person. We have not, as a group, endeavored to make our estimates any better since the consistency is working for us and we're ok with our velocity being consistently low.
The key to scrum, in my opinion, is feeding knowledge back into subsequent sprints. You learn a lot during a sprint, so be sure to use that knowledge to make the next sprint better. If something's not working out for you or your team, spend some time in the retrospective meeting to come up with changes that you can make to fix the problems. We're pretty far off from "by the book" scrum but I would say we're still embracing the spirit; it works for us, we adapt to changes pretty easily, and we get the stuff we signed up for done by the end of the sprint. Our variations come down to acceptance that fires will come up mid-sprint and we have a mechanism to deal with that that does not require the whole restart process.
