Jira sprint planning – let’s break this into pieces. What a sprint is and how to plan sprints in Jira? How to define goals? Is Jira Software enough for sprint planning or do you need an app from Atlassian Marketplace?
What a Sprint is?
Sprint is a Scrum term. A sprint usually equals to one to four weeks. In smaller organizations sprints tend to be closer to one week, in corporations – sprints are somewhere in the vicinity of three to four weeks. How come? Scrum, with its daily 15-minute meetings and 0,5-1 day planning sessions between sprints, is noticeable overhead for the big.
After a sprint a team gathers to revise the progress of the project and to plan the next sprint. Since SAFe® adopted elements of Scrum, the term became extremely popular in SAFe®.
Are sprint goals really Important?
Yes, and for a reason. It’s just practical to brief a sprint somehow, be it “Release new version of software”, “Arrange marketing campaign for product X” or “Build a new website”. These headers are in fact sprint goals that both keep a team motivated and facilitate retrospection. Could you quickly answer the question of “What was the last sprint all about?”, with 40 tasks attached to that sprint, without any goals?
Sprint goal vs. sprint objective
Goal is a Scrum term, and objective originates from SAFe®. Scrum recommends one goal per sprint and SAFe® allows for several objectives per sprint. But today these terms tend to be used interchangeably.
How to do Sprint planning in Jira?
Option 1: Just Jira Software (no special app)
Check the picture – this is how you would plan sprints in regular Jira Software, with no dedicated app. You create sprints and you can drag&drop tasks from a backlog to Sprint 2, Sprint 3, 4, etc.
As far as reporting, Jira will show project manager the number of issues per sprint and the number of story points, if used, per sprint.
What are the problem with this approach?
- Problem 1: Imagine an “average” organization with 5 teams of 5 members each and 3 issues per sprint per team member. 5 x 5 x 3 = 75 tasks / sprint. Is there even enough room for half of them with this vertical layout? How about if we planned several sprints ahead?
- Problem 2: Where to input goals? In the early days of project management, the 30-character “Sprint name” field was used to define the goal of a sprint. A project manager would typically put something similar to “S4 – Enhanced reporting” into that field, where “S4” stood for “Sprint 4” and “Enhanced reporting” would have been the sprint’s goal. But 30 chars would not typically accommodate a single goal, not to say about multiple goals per sprint or any tracking of individual goals. So in Jira 7 a separate and lengthy “Sprint goal” field has been added, but you’re not even able to break the line with Enter. And still no option to track individual goals, i.e. mark individual goals as ‘completed’ or ‘failed’.
Conclusion: with a single team, when you only plan the single upcoming sprint, plain Jira Agile might prove effective. With more than one team, and long-term budgeting and planning involved, you probably need an addon for sprint planning in Jira.
Option 2: Jira + a simple third-party app
By “simple app” we mean Sprint Goal and Agile Sprint Goals third-party plugins available on Atlassian Marketplace. They might seem obvious choices for those who are into Jira sprint planning. A closer look reveals that they add a text area for goals (multiple lines instead of one) and one of them allows formatting of text (a wysiwyg editor).
A warning light should go on, however, when you visit their “Versions” tabs on Atlassian Marketplace, with extremely rarely released new versions.
All in all they have most of the shortages present in Jira 7: no “big picture” provided, no individual and trackable goals and no SAFe® compatibility.
Option 3: Jira + SAFe® compliant BigPicture. Recommended for sprint planning
BigPicture is a project management app for Jira. Some call it powerful. It is very appropriate for Jira sprint planning, an obvious choice for larger organizations. What does it do better?
- Are there teams in your projects? BigPicture slices a sprint into team chunks.
- BigPicture lets you define sprint goals.
- A goal is either an arbitrary text, we call it ‘artificial objective’, or a linked issue from a backlog.
- You can set multiple goals for a sprint – individually, that is in separate fields, not in one single text area. Say you had three goals for a given sprint for a given team. The team completed two of the objectives, which you can now mark as ‘completed’.
- You could mark the third goal ‘failed’ and move it to the next sprint.
- You could track ‘failed’ goals and adjust planning accordingly.
- In BigPicture you can set goals both on sprint level and Program Increment level (4 x sprint = 1 PI)
- You could add ‘business value’ to goals to show priorities to your team. With business values in place, you could use SAFe’s Program Predictability Measure.
- ‘Set as stretch’ command available in BigPicture’s context menu, lets you visually cut off less crucial objective from the rest.
All this is achievable in the roadmap module of BigPicture.
How to set goals that both stakeholders and team members understand?
A good goal should consist of up to a few words. We, SoftwarePlant, had the “BigPicture Trello” goal on our roadmap, pictured, very obvious for our CEO, but less so for software developers. The attached tasks explained the goal to the team members.
Jira sprint planning Q&A
Golden rules of sprint planning
- A sprint typically lasts one to four weeks.
- Plan the current sprint and one future sprint. At most you should plan for a few months ahead.
- A team should be able to complete a given sprint goal within a single sprint.
- Roadmap is a great tool for Jira sprint planning.
How companies approach planning?
- Goal-centric approach. Goals would be determined up front for Program Increments and sprints. A team would later add tasks on a sprint-to-sprint basis.
- Task-centric approach. A project manager would sprinkle 200 tasks from the backlog pool over a lifespan of a project. Then the project team would keep defining goals on a sprint-to-sprint basis.
How to pick issues for a sprint?
You could have a backlog with hundreds of issues. Which to choose for the next sprint? There are several approaches:
- Apply priorities or “business value” to issues. Then select only the most urgent or valuable issues for the upcoming sprint.
- Select the oldest issues for a sprint – if they are roughly equally important or if your team neglects priority field.
- Green and red arrows appear automatically on BigPicture roadmap while you plan. You’re alright with green links, but red arrows indicate “invalid links, i.e. the ones that are not logically possible with the current plan. For instance, if a task linked with an end-start dependency starts AFTER the task it supposed to start before, the link will be in red unless these tasks are swapped in order”. Source: https://wiki.softwareplant.com/display/DOCUMENTATION/Using+the+Roadmap
Can an issue from a backlog constitute a sprint goal?
We’ve been taught that a goal should be something bigger or more general than an issue. So, is the answer: “No.” correct? Not really:
- “Big” goals are more appropriate for big teams and Program Increments. SAFe® says: a goal for PI should be more of a vision than an issue or task.
- The SAFe® compliant roadmap in BigPicture Cloud has a switch to facilitate searching for issues and setting them as goals.
- Setting a backlog issue as a goal for a sprint is especially appropriate with a small “team” of a single individual or a team of two.
How to estimate goals?