According to SCRUM standards, there is only one planning event: Sprint planning – a meeting that normally requires approximately 4 - 6 hours (time is calculated up to 2 hours per week of the sprint) and happens every sprint before to start it.
My opinion: it is bad practice to have regular meeting longer than 2 hours, there is something to do with it!
It is mentioned that there are also some grooming meetings (time to clarify backlog), but grooming’s are not specified very well, and the meeting is not necessarily about the planning of development.
I am a Project Manager. 14 years of project management, 5 years in agile framework, last 4 years in product companies, last 3 years in ABBYY, mobile technologies. I would like to share my practical experience, how we organized the planning in ABBYY Mobile Technologies having SCRUM feature-driven development.
From the business perspective, the planning is required in following areas:
Company requires yearly budgeting – it means, every year a development team should take some commitments about the planned development activities for next year. These activities should be formed out as a project, i.e., they should have a description of the goal and achieved results, and preliminary calculation of required resources for it (i.e. the cost). These figures are to be approved by top management.
We do not have implemented procedure of production deliveries by CI/CD paradigm. Having 2-weeks sprints we are not possible to finish every sprint by production delivery, and even to organize bi-weekly demos to stakeholders of production-ready features. For our B2C products (FineReader, BCR, TextGrabber) the development livecycle of anyhow significant feature is 2-3 months – I do not speak about our commercial SDKs (mobile capture and OCR) at all, where development lifecycle is significantly longer. Therefore, is absolutely not enough for us to have only sprints as a cycle of product development . We need to have another paradigm – Feature, which is always longer than 1 sprint. And it requires its own planning – setting multi-sprint development plan and milestones (at least, ready for test, ready for production, production). Production milestones are very required for marketing. E.g. milestones are required to satisfy some deadlines (e.g. Black Friday, exhibitions etc.).
How we adjusted the Planning procedure:
Estimating for budgeting is a series of Grooming sessions. Not the whole team participates there, but only the team leads. We apply a Planning pocker there, but we estimate in days. The estimation is very light, we don’t go through detailed requirements and decompositions for it. But, of course, some preliminary feature-introductions by Product manager and some preliminary dev-evaluations could be necessary. Each planning meeting should not be too long – not more than 2 hours.
… by the way, we still differentiate the roles of developers: Android dev, iOS dev, QA. Each of them has its own team lead.
As result we have a product roadmap, approved by top-management.
Before the next prioritized feature can be taken to development, we do the following:
Compose the document of Requirements (in Confluence)
Prepare correspondent UI-prototypes (Designer in Figma or Zeplin).
Discuss and agree Requirements & Design between Product Manager, Designer, Developers and QA specialists.
Decompose requirements into JIRA tasks – special meeting participated by developer and QA specialists. The level of decomposition here stops at elements of scope that are comfortable for both development and QA to transfers in status “ready for testing”.
Prepare Test Plans for the created JIRA tasks.
Estimate prepared JIRA tasks: separately Development and QA. Construct project plan (especially, if there are some interdependencies between them). Distribute the tasks preliminary among the sprints. Set Production milestone. For the estimation we use again a Planning pocker.
Check that the prepared estimations are consistent with the product roadmap. If any collisions are found, they should be discussed and resolved between development team and Product manager. Roadmap / current estimation should be adjusted correspondingly, all the performed changes are approved by Product manager.
All this happens when we are in progress on the previous feature (previous release) and takes about 0,5 – 1 month in background (not more than 10% time of sprint performers). I call all this, of course, grooming, i.e., planning as well. As a result we have artefacts of Requirements, UI-protypes, Project plan, Test Plans, and JIRA tasks.
Created JIRA tasks are not yet sprint level (especially for developers!) and usually require further decomposition in order to be taken into the Sprint. As I have written before, we do not like the perspective to sit all together 4 hours in planning meeting. Therefore we organize separate grooming meetings beforehand, somewhere during the previous sprint, where we prepare the estimated tasks marked as “ready for dev” / “ready for qa” i.e. sprint-ready.
Please note: it is Ok if the task is created and estimated at grooming meeting, but definitely not sprint-ready, because it has dependency to another task that is not completed yet! So this meeting is only for some preparations in advance, and not to cancel the Sprint planning meeting at all.
Ok, and what is the final step of planning? Exactly – Sprint Planning meeting we have the first day of sprint. The meeting is not very long:
every developer of Scrum team goes through the board, verifies estimated story points and commits, what tasks he/she planes to complete during the sprint. To complete means here to set them “ready for testing” (i.e. to do development + code review).
In the same manner QA specialists commits their efforts (complete tasks means here to make it “done” or “bug-fix”/”reopened”)
Of course, gathered commitments have some assumptions (e.g. some dependencies may implement some risks during the sprint). Therefore, commitments are not something very fast fixed, they are only intentions to achieve some goals. It may happen that some sprint tasks will be blocked longer than originally expected. Therefore, we try to have the groomed Sprint backlog a little bit larger than only for one sprint. And there should be a certain number of prioritized tasks that a person can take in case his/her initial plans are blocked. Otherwise, welcome to urgent extra grooming about to take the extra tasks into the sprint!
Man Days or Story Points?
Most commonly it is written that Story Points (estimation by comparison to the master Story) are easier and more accurate.
I’m not sure about that, but Ok…
But another argument, already from my side, is that SCRUM Velocity in Story Points is more precise to team continuous improvements than Velocity in Man Days.
Velocity = number of completed Story Points per sprint
Example: Imagine that developer has done only 5 m.d. during the 2-weeks sprint. Why? I see two possible reasons here:
Something unexpected happened and estimation went wrong,
The developer had only 50% of Focus Factor during the Sprint.
And thus, the two possible ways for continuous improvement:
improve quality of estimations (to make them larger, having padding for surprises ☹!), or
increase the focus factor.
But we lose here improvements such as inventing how to do the task more efficiently! When human productivity is increased, the estimate of the similar task will be less man days next time and more stories will be completed, but the number of man days inside the Velicity will remain the same – 10 m.d. – and we do not see the increase through Velocity.
On the other side, when we use Story Points, we measure by comparison – i.e. the estimation remains the same, and no padding is required 😊. But the number of story points per sprint will increase.
A little more theory about Story Points:
Story Points are about task complexity, but the complexity is measured against a chosen master-task. We prefer to have it middle-size, measured as 3 or 5 Story Points (you can take 1 developer executes 5 – 10 SP during the Sprint: this approximation comes from the idea that Story Point can be taken equal to ideal man days to start with).
Hint: In the beginning it is possible to take Story Points equal to ideal m.d. (!but do not forget to have a master-task as it is described above). And in some time, SP starts diverging normally from m.d.’s (because increase of velocity).
Story Point is related to classical man day dynamically. Man days can be calculated from Story Points following to current value of team- or individual- Velocity. In our case (2-weeks sprint), the formula is:
MD = SP * 10 / Velocity
Conclusions
If you do not fit into the Sprint boundaries with your development cycle, if you are bigger and not oriented on CI/CD, then you need to feedback to some ideas from the classical Project management on how to organize the missed pieces of development cycle. The planning is one of them. As the result, you get a hybrid of SCRUM with classic Project Management – thank God SCRUM is good embeddable (proven by SAFe 😊) !
It is possible to avoid long and boring Planning sessions. Do not try to do everything at once but spread the process among the sprint – and the life becomes easier!
Story Points are valid to be applied, at least on the level of short-term planning. Because it helps you to organize a better process of continuous improvement.
Ok, it seems that’s all about the planning. There is, of course the other part of the story – the verification of performed plan and continuous improvement – I mean, Retrospectives. But that is another topic, and about that I’ll write a separate article: ABBYY: Mobile Technologies – Retrospectives.
Thank you for your attention, and I would be happy for your feedback and your questions.
