Last week I got my first two-day-long program increment planning, or shorthand called PI planning. I did not know what to expect, but some were mocking about it and some were enthusiastically putting all big white papers on the walls in preparation of it. It looked promising and worrying at the same time: would this be a useless (or not) time-consuming behold of what the business would like to have or would it be a long refinement? Or a mix of both perhaps?
After two years working with a lot of pleasure at a start-up which tried to implement scrum, I could see some repeating issues arising (of course not shocking, while we are humans and perfect is never perfect, so no blaming at them at all). They were well-known and fully defined at retro’s and although we tried really hard to prevent them, they were never fully solved. Not if they were dependent on “other” teams anyways.
At the beginning, we had a hard time to keep up with the pace of the desires of the business. So, we just swam and swam and almost drowned in fixing things that were not implemented the way it was expected to be. I think we made a good progress in it though. We became more critical in the definition of done of stories and tried to trial the business more in what they would like to have, still in an agile kind of way.
But the main issue I found out to be quite hard, was that epics and stories were hard to define due fast changing business perspectives and the business was usually rather disappointed of what we produced and thus we were always fixing things and did not have the time to build a lot of new things, although expected of the business. So, it felt like a vicious circle which was really hard to come out of, although we all tried hard and were devoted to develop new features. As developer, I felt like walking out of a tunnel, but never seeing the light at the same direction; your main goal was vague and prone to changes, going on-and-on-and-on.
This month I started at a new company in a newly starting project and guess what? I already saw some issues matching those of my previous job, such as not-so-well defined stories already taken into the sprint, having a main goal but not knowing the epic and defined stories in it. Probably every (agile) company may have these issues more or less.
Is there a solution? Although preferable, I think not a one-size-fits-all one. There are factors that influence what you can do and what not; dependencies, motivations,
accomplishments of the team members and so on…
So… What can a PI planning do to help? What is it?
(I assume in this case, you are familiar with the process of scrum…)
A program increment is a cycle of plan-do-check-adjust, including a smaller group of sprint increments. It actually is a process described in SAFe, an agile framework which some like and some do not (like any other described process/framework or whatever). But I think you could do it without all the rules/processes of SAFe anyway.
All the scrum teams (with developers, PO’s and scrum masters) of the department are involved and it is valuable to have business not in a scrum team involved in the PI as well.
Starting last week at the PI planning, I reconciled the meetings of the last few months of my old job, where business presented their past, now and future vision and the conclusion of the IT was: you are behind of schedule. So, at the first presentations starting in the morning, I did not expect to get something else than that, although for me as newcomer of course a thankful welcome to dive into the business material and upcoming plans.
But after lunch, we started to breakout in the separate teams and we needed to go look at the white papers that hung on the walls – actually each paper defining a sprint. The main goal was, to estimate each sprint’s story points by availability of the team members and defining the backlog stories which should be taken into this PI, according to the core main goals just presented by the business in the morning.
We – as a brand-new team – did not have all stories yet defined, so we consumed a lot of time by making up & discussing new-made stories. At the end of placing all the stories, you had to place dependencies & risks to the sprints & stories.
After this team breakout, it was time to present all your draft of the sprint planning, with emphasis on the dependencies & risks; especially those dependent on other teams.
At this point we came to a conclusion, that one team did not have enough (development) resources and we had still some space in our sprints – although it indicated more uncertainties than really available time.
The last thing done that day, was the PO’s discussing these drafts. They spent another 2 intensive hours I heard.
The next day, we got to hear the changes made of the plans presented by the PO’s.
In our case, quite rigorous, because a whole epic was removed from our sprints as well as of another team. Pity? Yes. Necessary? Yes.
At this part, I felt a mixture of regret that we put so much effort the day before in defining that epic, but also a relief that this was now concluded – instead of in the next few sprints – as agile environments would do normally.
Then there was another breakout of the teams, to apply the changes and finalize the draft of the sprints, by defining the objectives for every sprint.
In our case, these objectives were reduced due the removal of the epic – and we should be missing a developer for some sprints in order to meet the other team’s shortage (although not the most desirable).
After this, we had a review of our plans with the PO’s also estimating business value of our objectives, a defining of all the risks with assignment to someone/something (resolved, owned, accepted, mitigated), a voting of all our team’s own PI and a retro.
Still valuable, but everyone was more quiet at this time than before and we all knew the PI planning should end as soon as possible.
So at the end of day two, everybody was kind of exhausted; we felt like doing something valuable, but also doing a lot of discussions and pre-work that could maybe have been postponed to other meetings.
Was it worth it? I felt like it did, especially if I compare it by my previous experience. The key thing I learned here, was that it so essentially critical business & development merge into each other’s goals & views on what has to be done and how.
We also learned in this first PI planning, that we should investigate the stories more beforehand & prevent too detailed discussions of the implementation of them, although you can never prevent it fully for estimating them.
Agility expects you to be flexible at every moment, that you can adapt every new request of the business. But the key in this is, that both sides need to keep communicating to each other (making time for each other!) and both need to change their expectations. Else, you get finger-pointing to the weakest link.
PI planning cuts a bit in the agile way of thinking, because you define more beforehand. Is that bad? That really depends on the situation, but I prefer to say no. Sometimes we need control, we need insight even though we are said to do all things in a flexible way. What is better: finding risks beforehand and by knowing them already setting a plan to prevent them (even if that plan is maybe not preventing it fully in the end) versus going through the outcoming problems of the risks and trying to reduce them, while not actually having time (both business as development) to do so?
I know some (especially the developers) will find it a horror to discuss for two days. But I find it a horror to discuss at other not (or last minute) planned moments, while I could be doing other more productive (and planned) things at that moment.
Furthermore, I am middle ground seeker and believe that you can be more flexible in implementing this kind of planning, so that the hours it takes to plan will be shorter. And after more experience and preparation comes also more time saving.
These questions, experience and more other questions with subjective answers will decide if you find it valuable to do some sort of this plannings. My first experience was overall positive. We will see in the future if other parts we will use of a PI will also help in our development process and if the next PI planning will have the same efforts.
For further reading of this process, take a look at: http://www.scaledagileframework.com/pi-planning/