Rekall Roadmap

For the first release of Rekall we had a simple goal in mind: to offer as soon as possible a tool that would help you improve your estimation process. Of course Rekall will evolve based on your feedback and feature requests but we also have a lot of features that we want to add in the upcoming months. So, if you are not convinced yet about the value of Rekall, here are some of the enhancements that we are planning:
  • Customization of the estimation field. Currently, Rekall only supports story points set following a pseudo Fibonacci sequence like the one used during Planning Poker sessions. In a future release, you will be able to fully customize the estimation sequence. If you use a different story points scale, you will be able to do it all in Rekall.
  • Reestimation of issues. Rekall also wants to support teams that do regular backlog grooming by allowing to re-estimate issues that have not yet been executed. This new feature will allow a user to change the estimate of an issue if no work log has been registered since users may want to change their initial estimate when they get more insights into the project.
  • Metrics on the range of effort required to produce a Story Point. In order to be an effective estimation and planning technique, story points must be linear. This means that a 2 points user story must require roughly twice the effort needed to produce a 1 point user story. Story point estimations are fairly linear up to 3. However, when estimating user stories at 5 points and above, teams often fall into an exponential trend. The Metrics feature will give you the tools to ensure that your story points are roughly linear across the entire range of estimates thus giving you the confidence that undertaking a bigger user story within a sprint is possible
  • Warning when a user story has not been properly estimated. During the Sprint Planning, the team will break down a user story into technical tasks and provide a time estimate for each technical task. Rekall will use these time estimates and validate if the story points estimation matches with the work planned. If it finds that there are too much discrepancies, it will propose you to re-estimate the story using Triangulation so you can set the proper number of story points before the sprint actually starts.