A1QA Blog

QA Core for Executives

SAFe vs. Scrum, and PI Planning Essentials

Let’s continue our talk about the SAFe framework that helps get the best of agile methodologies in large development teams. In this article we’d like to shed some light on the SAFe differences from Scrum that are to be considered by the development and QA teams who have migrated from Scrum and have no previous experience with SAFe.

First things come first. SAFe is an agile framework by nature and it is founded on the principles declared in the Agile Manifesto. One of the postulates states, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”.

Obviously, it isn’t very hard to follow this principle with 10 specialists developing and testing software. With 100 specialists involved, the situation gets, mildly speaking, more complicated. Is there a solution to sync up the work performed by them all?

SAFe takes communication to the next level and introduces PI Planning to promote direct communication between the attendees: software developers, testers, business owners and program stakeholders. PI Planning is the synchronization point of the Agile Release Train.

Why PI? During the planning session, the teams create the plans for the upcoming Program Increment (PI). PI Planning is a very significant event and essential to SAFe success.

How Is PI Planning Organized?

It’s better to see something once than hear about it a thousand times, they say. With this saying in mind, we’ll share our planning agenda we received attached to the Meeting Request email last month. You’ll find the agenda some paragraphs below, while right now we enlist some of the crucial points of planning.

Prior to planning, the well-elaborated Backlog of functional and architecture features is prepared. The results of the planning shall be the commitment of the teams to an agree-to set of objectives for the next PI. All planning takeaways (teams committed to work on any user story, user stories interconnections) are fixed on the Program Board.

The planning process itself is very fascinating in SAFe and has many teambuilding features.

Let’s review some of the major differences our QA team has come across.

Organizational Issues to Be Ready For

  • Duration. Previously, it took us less than four hours to plan up a Scrum sprint. After migrating to SAFe, planning began to last four days almost.
  • Participants. While applying Scrum, we planned sprints independently from other teams. In SAFe it’s all different. Development, QA, business analysts, UX specialists are to participate in planning cooperatively. If someone can’t attend it for some reasons, he or she should be available for questions.
  • Event Agenda. In Scrum, most of the time is devoted to estimating user stories. In SAFe, there are many more stages.

Now have a look at the agenda of the Product Increment planning we had last month.

It all starts with the company’s governing bodies communicating the Business Context of the upcoming PI to all teams. After that, the Product Manager specifies how the Business Context will be implemented in terms of functional solutions. The Architecture shares his/her vision on the product’s technical implementation.

When they are done, the floor is yielded to the Product Owner of every team. The Product Owner briefly presents the scope of requirements for all the team to be familiar with the features that will be developed by every other team. On that note, the first day of planning is over and teams say goodbye to each other to meet the following day.

On day two, teams break out to start working on their plans for the upcoming PI. By the end of the day, the draft of the plan should be presented. Managers review the plans drafted by the teams and introduce necessary adjustments.

During the third day of planning, teams continue working on their plans to finalize them. Scrum Masters present the plans of their teams and review the risks alongside. The final procedure is Confidence Vote. All attendees should confirm their commitment to the final plan objective. Every team conducts a “fist of five” vote. The commitment is accepted if there are three or four fingers in average. If fewer, then plans are reworked.

Noteworthy, any person voting two fingers and fewer should be given a voice to explain their concerns.

Finally, a brief retrospective is conducted to capture what went well and what did not. Following this, next steps are discussed.

Ways to Sync Up And Visualize the Issues

  • If you were attentive (and we bet you were) you must have noticed one of the points in the agenda we haven’t specified yet. Scrum of Scrums Hourly. It’s an hourly meeting of Scrum Masters that take place while the teams are estimating the given user stories. The objective here is to sync the teams up.
  • New level of visualization. Working with Scrum, we used JIRA to track bugs, assign issues to the responsible specialists. In SAFe, it became very difficult to discuss arising issues with colleagues who are allocated on other continents. Having tried multiple options, we gave our preference to RealtimeBoard – virtual boards that allow us to work with visual content together with our mates.

Stories Estimation Differences

  • Estimation methods change from those in Scrum. User stories in SAFe are estimated in story points. This is the relative estimation to compare the difficulty of two or more stories.
  • Every story is to be estimated in 2-3 minutes. Teams don’t need to get into deep discussions but rather provide general estimation.
  • If the story is estimated in more than 8 points, it should be broken out in smaller pieces to be implemented on time.
  • Now in SAFe we not only estimate our job but also the job of our colleagues from other teams. It gives better understanding of their contribution and engagement. The question “Why do you need so much time for testing this small feature?” is rarely heard now.

PI Planning Advantages

The key advantages of planning in SAFe are the process transparency and team face-to-face communication.

The future has become more definite as we are aware of the teams’ plans several sprints ahead. Besides, we’ve gained better understanding of our mission and the value we add to the product.

Thanks for stopping by, we would appreciate your opinion.

Share this: