Alexander Lemm on November 23, 2016 How Software AG Implements Scrum using Planio
We are a happy Planio customer using a customized Enterprise Planio instance since 2010. Initially, our consulting division used it to collaborate with our own customers in projects. Soon, other departments like Sales and R&D discovered it and leveraged the platform for their own purposes as well. At this point in time our Planio instance has approximately 2800 active users and 3000 active projects.
Planio provides excellent agile project management support via the agile module such as the sprint planning board, the task board and various agile charts.
In this article we will highlight some of the best practices we have derived and applied at Software AG in our agile projects using Planio. We will focus on setting up our project, user stories, tasks, boards, and communication in general.
Creating Sprints
First, we start by adding our sprints in the settings module. Here we can add our desired number of sprints, the starting date of the sprint, and perhaps a duration or the sprint goal in the description.
Creating Categories
We can also add categories within the settings module, which will appear as a drop down menu on all our issues. You can define categories per your project needs, but they should give the sprint team an idea of the kind of work that the task involves.
User Stories
User Stories are high level features described using a non-technical language which can be explained easily to customers. Each user story encapsulates several technical sub-tasks. However, those sub-tasks are not used when communicating with the customer. They are only of interest to the development team and added to the user story during a sprint planning meeting one or two days before a sprint starts. Typically, a user story consists of 3 parts: the title, the description and the acceptance criteria:
It is a no-brainer to see that at least the title and the description of a user story can be encapsulated in an issue. We use a dedicated tracker named Feature Request to represent user stories in our Planio instance. It is not called "user story" because the agile module was added a couple of years after our initial Planio launch and we didn't want to add an additional tracker.
But what about the acceptance criteria? For this we use checklists, which are an optional but integral part of an issue. Each acceptance criteria is added as a separate line item to the check list. In this way, all 3 major parts of an user story are included in a single issue.
But what makes check lists even better?
During sprint review meetings the customer or product owner himself, who is usually a project member, ticks off the acceptance criteria in the check list.
We found that the direct participation of the customer in this process had a positive impact on the development team's motivation. Additionally, dev team members who can't participate in the sprint review meeting can see the customer's accepted test criteria just by looking at the issue's history the next day.
Tasks
A task is a technical piece of work necessary to get a user story done. As such, it makes the most sense to represent tasks as sub-issues in Planio that are associated with the respective (parent) user story. We use a specific tracker type for this, which is also called "task".
We see very little value in tasking out user stories that won't be part of the next iteration. Therefore, we always elaborate tasks in sprint planning sessions directly before the next iteration. The development team itself defines the tasks.
The User Story Lifecycle
All user stories initially appear with a 'New' status without a sprint assigned; this is our Product Backlog. During sprint planning we decide which backlog items we will take into sprint, and the respective sprint is assigned to the user story. From here we start progress on the sub-tasks which were added to the user story until we believe all criteria as per the checklist on the user story have been met. We are then ready for acceptance.
If necessary, a feature request can be moved back from "Closed" to "In Progress".
The Task Lifecycle
The task status should reflect its progress within the sprint. When we see a status change, it's because progress has been made on the task. When this happens, we can also see the Assignee change; predominantly from a developer to a tester.
As the task is completed, this in turn updates the progress of parent task, which in our case is the user story, as mentioned above earlier.
Agile Boards
Another handy feature in Planio is the Agile Board which mimics the classic Scrum board. A project can have many agile boards which are configured in the same fashion as issue reports using the filter settings.
In general, we work with three different types of agile boards:
- User Story Board: This board only shows the user stories and their current status. It is the main board when having sprint review meetings or discussions with the customer.
- Sprint Board: This board shows all technical sub-tasks that the development team has assigned to the current sprint. It is the main tool for the team when having daily scrum meetings.
- General To-Dos: Of course, each project includes tasks which are not directly associated with a sprint; for instance, ideas discussed and identified in retrospectives. All of those sprint-independent to-dos are tracked using the General To-Dos board.
Communication
We often collaborate in virtual teams including members of our offshore centers in Eastern Europe and Asia. Therefore, communication is absolutely key for us.
Experience has showed that email should not be used as the primary communication method in those setups because the risk of missing important requirements clarification or design decisions is far too high. All communication must be conducted through a central collaboration site, which in this case is the Planio project itself.
One Planio feature which was underrated, or at least overseen for many years in our company, proved to have a big impact on communication and thus project success: the blog module.
When working in virtual teams that include multiple nationalities the daily scrum meetings usually take longer than 10-15 minutes. On average, we spend approximately 30-40 minutes on them using web conferencing to create a sense of proximity between team members. Summarizing and publishing the minutes of the most important findings and topics of the daily scrum meetings proved to be of high value. When questions come up, the customer, who also receives an email containing the blog post, can directly jump in and clarify open issues raised by the dev team by leaving a comment underneath the article. 
In addition, the minutes of sprint review meetings and retrospectives are also distributed and discussed that way. Similar to the checklist effect discussed above, we found that the direct involvement of the customer had a positive effect on the team: everyone was much more engaged and pleased when working on the project.
Also project onboarding gets much easier when using this communication style. A new team member simply needs to read the last blog posts in order to be up-to-date quickly. In addition, the most important project communication is preserved in the project itself and easily searchable if necessary.
That wraps up our overview of how we implement scrum using Planio. I hope that you enjoyed the read and that our agile best practices will be useful for your projects as well.
