This is the last article in our three-article series comparing BigPicture with Structure apps for Jira.
This article will cover features supporting Agile approaches to project management.
If You missed our previous articles – click here for an article about creating hierarchies, or here for the one describing features supporting the Waterfall approach.
Both Gantt and Resources are used mostly in Waterfall or Hybrid approaches. What features are available for Agile?
BigPicture has two main modules oriented for Agile. It is worth mentioning, that BigPicture is certified to be compatible with SAFe (Scaled Agile Framework), which does not mean that it cannot be used with other Agile approaches – we performed successful BigPicture implementations with other Agile approaches too.
For purposes of Agile planning, BigPicture uses Sub-boxes of our main box used for planning. Each sub-box is representing Iteration (In simple SCRUM these will represent Sprints, in SAFe there will be two levels of sub-Boxes – Program Increment and Iteration).
These sub-boxes are visible in two modules mainly used in Agile planning – Board and Roadmap.
The board module is used to plan issues for specific Iterations. It can be done by dragging the issue from the backlog (visible on the right side of the module) to chosen Iteration/Sprint.
In the case of multiple levels of sub-boxes (like Program Increment at a higher level, and Iteration at a lower level) Planning on a higher level can be done first – it is usually mid-term planning, as Program Increments can last months. When this planning is done, the user can access the lower level by drilling down into program Increment and start planning lower-level boxes/Iterations. On this level, Backlog can display only issues planned for Program Increment that we drilled down into. What is more, new issues can be created from this screen, if a certain piece of work will require further breakdown.
On the Board module, no matter the box level we are on, we can see a lot of useful information:
- Swimlanes with Teams, which make it possible to plan each Iteration/sub-box for multiple teams at the same time
- Information about Work progress or capacity allocation – depending on display setting. This information is available for each team, and as totals of all teams for each Iteration. Thanks to that it is easy to track progress, monitor velocity, and check how much more work we can plan for future Iterations.
- Dependencies between tasks, allow identifying dependencies between issues, including ones assigned to different teams and iterations. In our experience, it is extremely important to identify these dependencies to make sure, that one team is not blocked by work that has to be delivered by another team.
What makes this possibility of planning issues in the Board module are three additional features.
First of all, Sub-boxes can be synched with Jira Sprints. We can have a sub-box representing Iteration, and assign issues to two teams in this sub-box. These issues will be automatically added to Jira Sprint or Sprints that are associated for each team with this Iteration sub-box. This sync works both ways – so issues assigned to sprints will appear on the Board module in the correct iteration! Thanks to that we have a lot of flexibility when organizing work – depending on how teams are working we can do whole planning in the Board module, or do only high-level planning there, and allow Scrum Teams to plan Sprints by themselves on Jira Boards.
Secondly, issues planned for each iteration can have start and end dates set automatically to reflect the Iteration in which they were placed. It will automatically put these issues in the correct place on the timeline in the Gantt module, on which we can also display information about when each iteration is scheduled to. Thanks to this feature hybrid approach to work is possible – some teams can work using the Agile approach, some using Waterfall, and plans of all of them will be displayed on Gantt in a unified way.
Finally, the content of cards representing issues that are visible on the Board can be customized, allowing easy access to information that is really relevant to users.
Except for the Board module, BigPicture offers, already mentioned, the Roadmap module. This module operates on the same sub-boxes as the Board module but is used to define and monitor progress on high-level objectives that should be achieved in each sub-box (whether it is Program Increment or Iteration. Objectives can be Jira issues, but usually, they are just text visible only in BigPicture. Objectives can be general, applicable to everyone, or team specific. Each objective can have a percentage progress set, and be marked as Achieved, Abandoned, or Not achieved.
The way Roadmap is usually used is, that definition of objectives for upcoming Program Increments of Iterations is the first step in planning. When this is done, Everyone involved can start discussing what steps should be taken, so that the objective can be materialized. This is done in the Board module either by identifying and creating new issues or just planning existing issues to the right sub-box. BigPicture allows displaying objectives that were defined on the Board module too! Next to the planned issues. Thanks to that we can easily make sure that all of them were addressed in one way or another while planning issues.
Now, let us look at how Structure enables Agile planning.
Not so long Ago, Structure had little to offer in that area. It could automatically set start and end dates of issues when these got assigned to sprints (like in BigPicture), display When Sprints are located on the timeline… and not much more.
But that has changed! With Cross-team PI Planner (that is at the time of writing this article in early access, so a lot can change there. Also, it might not be widely available yet) Structure offers much more, and closed most of the gap to BigPicture in that area.
Cross-team PI Planner allows the creation of additional Boards of four types. We will mention them all but focus only on the Sprint PI Planning board, as it seems to be most useful for Agile planning. All of the board types share the same layout – Backlog on the right side, allowing to drag and drop issues when planning. On the main screen on board, we can see columns and swimlanes. Issues placed on board will be represented as cards, with information about dependencies existing between them.
Available board types are:
- Roadmapping Board is a board that has fix versions as columns. Swimlanes can be defined based on chosen field or dependency type.
- Agile and Custom Boards are a bit more flexible than Roadmapping, as both Column and Swimlanes can be defined by the user based on Jira fields, including e.g. issue Status.
- Sprint PI Planning is most similar to BigPicture Board Module. There are two main differences:
a. Planning can be done only on one level – Sprint. In case we have time boxes grouping sprints, like Program Increment, it is not possible.
b. Columns on this board are synchronized with Jira Sprints, like in BigPicture. But the possibility of configuration is more limited – each team needs to have its own Jira board with separate Sprints. That could be the case with the BigPicture, but there we could also have multiple teams working on a single Jira board, on the same Sprints.
All in all, this is the second Area where BigPicture is more advanced, but Cross-team PI Planner is a step in the right direction. Also, in cases where planning just on sprint level is sufficient and we want to have the possibility of creating additional types of boards, Structure with Cross-team PI Planner might be better suited for our needs.
There are some features, that were not mentioned earlier in this article, as they might not be strictly Project Management oriented or they are not available in the other app, so cannot be compared. These are still worth mentioning:
- Structure has the possibility of creating so-called formulas. These are fields visible in Structures, that can calculate some information and display it in the manner the user intends to. Creating that king of fields requires some technical knowledge, but this feature is a powerful one, as it can be used e.g. to:
- Perform calculations based on issue fields, item properties, or other attributes
- Compare values from multiple fields
- Create visual notifications
- Grouping, sorting, or filtering items within the structure, using Generators
- Writing data to Jira fields2. Big Template is another App that works with BigPicture, allowing to export BigPicture and Jira data to files (PDF, Word, Excel, etc.) based on templates, that the user can define.
3. Both Structure and BigPicture expand Jira with additional JQL functions.
4. BigPicture has some additional modules oriented toward Risk management and reporting. These are simpler modules with fewer features than the ones discussed in this article.
Below you will find a score (1-10) for chosen areas of these tools, with a short comment. Please keep in mind that this score is subjective, and based on our experiences. There can be cases where a tool that is scored lower fits specific needs better. So it is always good to perform requirement analysis before going for one tool or another.
|Area||Big Picture Score||Structure Score||Comment|
|Building issue hierarchy||8||10||Big Picture offers good possibilities in building issue hierarchy, but Structure is more robust and flexible in this area.|
||9||9||Works similarly in both add-ons|
||5||7||Only one baseline in the Big Picture. Multiple baselines possible in the Structure.|
||8||1||No Scenarios in Structure. Big Picture offers possibilities of creating alternative plans, but they are limited to issue start/end dates (without the possibility of creating alternative dependencies or assignments)|
||9||9||Dependencies (start to end, start to start, etc.) offer similar functionalities. On top of that Big Picture offers more robust parent-child dependency behavior. Structure, on the other hand, allows interpreting different link types as the same dependency via slice configuration.|
||9||8||Similar functionalities, with BigPicture taking lead due to better parent-child dependency handling|
||8||7||Most important warnings (not respected dependencies, wrong start/end dates) are available in both add-ons. Big Picture offers additional warnings. In structure Formulas that would be used as warnings could be created, but it is excluded here, as formulas are rated separately.|
||9||6||Possible in both, but Big Picture has it solved in a more intuitive way.|
||9||7||Possible in both, with Big Picture having more granular possibilities of changing capacity. Additional velocity information available in Big Picture|
||9||6||In all these elements Big Picture has more features and is more intuitive.|
||1||8||Structure allows us to treat value in any field as a resource, so resources that are not related to Jira users (like hardware) can be handled by it.|
||5||7 (10 with formulas)||Big Picture has a dedicated module, but it is far behind any reporting app. Structure does not have such a module, but other functions (like Formulas) handle reporting very well. Due to separate scoring for Formulas, Structure score is slightly decreased here (it would be 10 with Formulas included!).|
||8||4||Dedicated module in Big Picture. Structure can be handled with the use of non-dedicated features.|
||10||10||Available in both.|
||7||9||Both apps add additional JQL functions, with Structure being slightly more robust here. Additionally, Structure has a more advanced concept of S-JQL.|
||1||10||An advanced feature allows making Excel-like spreadsheets from Structure. Requires advanced knowledge, but is powerful. No alternative in the Big Picture.|
||10||8||Both Apps allow granting permissions to users, with BigPicture permission set being more robust. Both apps respect Jira Permissions.|
||10||8||Both Apps can support hybrid approaches to project management, with BP taking the lead due to better handling of Agile.|
||8||6||JQL search available in both. Big Picture allows you to define quick filters, and perform text and date searches with UI.|
||8||8||Both Apps allow in-line editing of issues, both do not allow editing everything.|
Both Big Picture and Structure provide a wide set of features supporting management on multiple levels (Project, Portfolio, Team, etc.).
At the moment Big Picture comes on top in the comparison with Structure – it seems to be more mature and its management-oriented features are more robust.
That being said – there are features (like formulas) that might turn out to be very useful in addressing specific needs that BIG Picture could not address. What is more, ALM works (creator of Structure) takes big leaps in addressing gaps (like creating a new app to support Agile planning). Additionally, ALM works have been acquired by Tempo – so we may expect more integration between these two.
Have any questions? Contact us!
If you would like to learn more about BigPicture, talk about the best way of using the tool available in your company, talk about possible training or implementation help, and remember that in Genius Gecko we are the experts in this area. We are working with BigPicture almost from the beginning and we are probably the most experienced people in the world currently when it comes to BigPicture project management. We might also add, that we are not the most expensive! 🙂
Don’t hesitate to reach out to us for a free first session during which we will help you get the most out of this amazing Project Management tool.