Experiment with Sprint Planning

"Methodologies just add more meetings. It just slows us down and makes us unproductive!"

The freedictionary.com definition of unproductive is "Not productive; idle."

Agile does not mean no planning. In fact Agile means you plan all the time. If this does not make sense then I advise you to go read the 12 Agile Principles here. Please try to dig deeper into them and make the 12 principles work for you in your day to day work life for at-least a 2 month time frame. If you really try and make it work for you and try to implement the principles in your day to day work life then probably you would understand what I mean when I say you plan all the time and you would understand what being Agile really means.

When you are Agile, you avoid phase driven planning sessions. Planning happens rhythmically and at an appropriate time involving only the required people. Also a lot of impromptu planning happens during the software life-cycle. This planning is mainly based on the inspect and adapt principle and the inspect and adapt principle is based on the empirical process control theory.

In Scrum we plan during the Daily Stand Ups, Sprint Reviews, Sprint Retrospectives and off-course during the Sprint Planning meeting. Planning == inspecting + coming up with adaption strategies. Sprinting == wasting no time in phase driven philosophies and implementing the adaption strategies to ship out working software to users.

Let's assume we ban all the Scrum meetings and just start working on stuff organically. In this scenario we would need some really awesome organic osmosis to happen to make things work isn't it? Organic osmosis does happen, but only in small scale teams who know each others working styles really well. When you try to scale organic osmosis, there are high chances that it may fail terribly.

A key principal in Agile Planning is Just in Time, and just enough planning! This balance has to be maintained always, while being agile. Implementation time of the User Stories should be when the requirements meet the INVEST principle. Independent, Negotiable, Valuable, Estimable, Sizable, Testable.

Arguably, if you fail to plan, then you would plan to fail!

Prioritizing Story Cards in Scrumban

How the heck do I prioritize this?

If you are a passionate Product Owner this question may have popped up in your head several times while grooming your Product Backlog, especially when its nature becomes very dynamic.

In Scrum, a tool mainly used for prioritizing is the ROI calculator. It makes sense to use the ROI calculator when the User Stories are chunky and the product Backlog is more stable but when you are doing Kanban or Scrumban managing story card priorities is a completely different ball game!

One could argue that setting deadlines over ROI values is a more sensible thing to do in Kanban. It may not imply that ROI calculations don't help at all and should be banned but when the Product Backlog is so dynamic, ROI numbers don't really help much in arranging stories according to priority. Everything seems to have a high ROI! What is more likely to differ though are deadlines on the stories. So why not use deadlines to prioritize work? It is also a very natural thing to do.

Setting deadlines on stories really puts priority in perspective for the Team members doing the tasks and it also helps the Product owner wrapping his head around a dynamic Product Backlog as far as priorities go. Off-course this is not a silver bullet but just my observation.

Other crucial aspects to use while prioritizing stories are revenue or loss, and availability or unavailability of resources.