A good solution depends on a deep understanding of the job people are trying to get done. Starting with why. Sprint Planning and refinement meetings are about bringing clarity to what to build, how it’s going to be built and why. Clarity is achieved with an ongoing discussion with the team, users and other stakeholders.
Story estimation is a tool allowing the team (and other stakeholders) to make decisions about options that come up during backlog discussions and development. Why is this important? Because first generation tools on the market (current solutions) fail to help teams run their planning and refinement meetings effectively.
This is because first generation tools focus on estimation solely, breaking up the quick pace of activities teams need when discussing a story. Teams need to move quickly from discussion, viewing a mockup, keep track of decisions, new information and also run story estimation. This is why story estimation needs to be available directly within the backlog. This can be clearly seen by users of first generation tools who bluntly state they can’t find any good solutions.
‘We have tried everything with little to no success’
Why are users struggling? By decomposing the sprint planning and estimation process it clear these tools wastly complicate the Sprint Planning process - see the article Planning Poker that doesn’t slow you down for more info, but here is the short story:
Finding a better way for Sprint Planning Estimation within Jira
When mapping out the whole Sprint planning process, involving current planning poker tools, it becomes clear where things go wrong. It is the impact these tools have on the end to end Sprint planning proocess and the complexity they introduce. The solution is to build on top of a strong foundation, the Jira backlog. Add critical actions missing from Jira to handle planning poker estimation efficiently and effectively. In summary move away from complexity back to simpicity:
In essence the solution is to:
- Not ask users to create and manage a separate list of stories. Why manage an ‘estimation backlog’ when ‘the backlog’ already exists?
- Not ask users to name the planning session, invite team members, etc. There are other tools perfect for this. Slack, Calendar, etc. Why spend time on things you can skip without any drawbacks?
- Allow teams to run planning poker directly where the discussion takes place, in the Jira backlog I.e. don’t take away the actions users depend on during story discussion
- Support one click estimates Why spend time on more clicks if you really only need to one?
- Make Planning Poker flow seamlessly for remote and co-located teams. By giving users the exact same information, as if everyone was sitting around the same table
This allows Scrum masters to use their time where it's actually needed. In summary teams get the benefits of:
This in turn allows you and your team to remove 20+ steps from your planning process altogether, compared to first generation planning poker tools currently on the market.
So how does Smart Guess work?
Notice that when this is written it’s only an early version of Smart Guess that is available and therefore there are many improvements yet to be done:
- Doesn’t work perfectly on mobile
- Only supports story points estimation
- Is currently only available in english
Therefore I would ❤️ love to hear if Smart Guess works for you. If Smart Guess doesn't work for you, I would love❤️ to understand why. Here is a link were you can be in contact.
Here is a short video of how Smart Guess works:
Smart Guess is available on the Atlassian Marketplace for Jira Cloud. It takes only a minute to install, only few minutes to see how it works and saves time every sprint.