With an objective to enable continuous learning and progression for our learners, PremierAgile curated several learning articles in the areas of Agile, Scrum, Product Ownership, Scaling, Agile Leadership, Tools & Frameworks, latest market trends, new innovations etc...
Many businesses like yours have a lot of confusion when it comes to using SAFe Program Increment Objectives. Often these confusions lead to resistance in using them. Also, they lead to the creation of badly formed team objectives that show up to be entirely redundant. The reason is that the team objectives just catalog the features being concentrated. The goal is to create useful and well-informed objectives for everyone to understand why they are very much important.
PI Planning aims at generating alignment and permits teams to plan, estimate and innovate their own work. It is a part of the SAFe approach to mission planning. The business owners present the overall goals of the list of the features and PI to the teams to come up with the objectives. These objectives will express the particular timelines and actions for achieving goals.
Program Increment or PI Objectives are a brief of the technical and business goals. It summarizes the aims of an Agile Train or Team, which the team intends to attain in the forthcoming Program Increment (PI). In the process of PI Planning, teams generate PI objectives. These are things that they wish to attain in the forthcoming Program Increment. You might wonder why teams do it. Here are some reasons:
SAFe depends on a rolling wave of instant dedications from teams that practice Agile methodologies. Also, it trains to back with planning and results in a business. In turn, it helps with improved association and faith between business and development stakeholders. These dedications are communicated using PI Objectives. Of course, development is not evident naturally. Nevertheless, a business can rely on teams for a certain level of predictable and dependable forecasting. When the forecast is too much, the business will have a commitment to long-term plans. In turn, it can restrict the agility of the business. But, when it is too little, it will not be possible for businesses to plan. This is why technology and business stakeholders require something in the middle. This is where PI objectives are helpful. The method of setting sensible goals also helps businesses keep away from the higher number of work-in-progress in the system. As teams recognize them at the time of PI Planning, PI objectives are often built bottom-up.
When they engage in PI Planning, teams are bestowed with new features. They propose the stories they should deliver together with stories that denote efforts from their local environment. You can explain this work as a collection of particular PI Objectives of a team. To do the same, you should do estimation and planning. Also, it needs to analyze the forthcoming features, team capacity knowledge, and describing stories for the backlog of the team. Above all, the information should be summarized such that every individual can understand it.
As far as the total number of program increment objectives that a team should determine, there are not any particular rules. Nevertheless, SAFe recommends 7-10 to be the best number. When the number is high, it might turn hard for the teams to understand the specificity of the objectives. Also, it will lead to an increase in the number of objectives to be reviewed. On the other hand, when the number is low, the aggregation or abstraction can turn very high to be evaluated at the close of the PI. Here is an image example of a team’s PI objectives:
Source: Scaled Agile Inc.
The PI objectives of a team generally correlate straight to the intended features. In fact, you can find many features and PI objectives similar. Nevertheless, the plotting is not always clear-cut. The reason is that many features need the association of many teams in an organization. The image below can explain it better:
Source: Scaled Agile Inc.
Some features like feature A are possible to be produced by a specific team. But, some features like feature B need an association of different teams. Further, apart from inputs to features and features, other objectives of the team will also show up. These can encompass technical objectives that enable milestones, improvements to development set-up, future features and others. Every outcome of the process of planning is considered in the objective of the teams.
The good thing about PI objectives is that they help shift attention off developing features. Rather, they will help teams to pay attention to attaining the preferred business results. When teams have direct conversions with the business owners, they can gain a better knowledge of the intention offered. In turn, the teams can provide new viewpoints to quickly find ways to use their proficiency for the creation of better solutions. Even, they can provide new ideas to product management and system engineering/architects.
Teams can build trust in the minds of stakeholders by doing one thing. Yes, they can commit to and can deliver a sequence of short-term goals. When stakeholders gain trust in teams, they can go ahead with confidence. In turn, they can base their plans and decisions on what will become a reality soon. On the other hand, they cannot plan things with uncertainty as research and development turn tough. Of course, things cannot always go as planned. To handle such things, it is better to build some small amount of buffer into the system. When the buffer is too small, many commitments might turn out to be hard to achieve. As a result, confidence can erode. When the buffer is too big, less might be achieved. How to handle this situation? SAFe recommends teams use both uncommitted and committed objectives when they plan. The good thing about uncommitted objectives is that they help to improve the expectedness of producing business value. The reason is that they are not part of the team’s commitment.
When it comes to uncommitted objectives, they are helpful with identifying work that can be variable within the scope of Program Increment. Even in this case, the work is planned. Nevertheless, the result is not certain. Teams can use uncommitted objectives as and when there is a low level of confidence in the meeting of objectives. Teams can become not so confident about the outcome because of too many reasons. For instance, when they will have to rely on another team or supplier, who they cannot guarantee this can happen. Also, this can happen when a team has no or very little experience concerning the functionality of this type. In these cases, the teams have the option to plan spikes early in the PI for bringing down uncertainties.
When respect to the benefits of PI objectives, is your team wondering whether to choose committed or uncommitted objectives? If so, it is better to understand how uncommitted objectives can be beneficial:
Without uncommitted objectives, a team is committing to a 100 percent scope in a fixed timebox. This pushes the teams to compromise on quality or they can build other buffers into the system. In turn, there are chances of accumulation of other buffers. As a result, there are higher chances of conversion of uncertain earliness to certain lateness. The outcome will be lesser overall throughput.
When there are uncommitted objectives, they denote a difference in scope. In turn, teams can gain confidence in the delivery of their main priorities. Delivering on the committed timeline is an important factor to build trust between stakeholders and teams. Teams focus on main priorities and deliver them on time. So, they can gain confidence and relationship building with stakeholders.
To deliver dependably on a given tempo, uncommitted objectives can provide the teams with the capability margin required for meeting commitments. Also, they get the power to alter priorities when needed.
SAFe PI objectives for teams give the summary of a team’s plan for the Program Increment. So, they have great value. At times, the descriptions might be a little vague or technical too. To handle this, it is better for teams to make their objectives SMART. What does this mean? Let us find out here: