Demo Support
February 07, 2022

Requirements in BigPicture. How to gather and complete them? (5-min. tutorial)

Requirements function in both agile and classic environments. Agile has found the “human face” of requirements by naming them user stories (as a user I want to… so that…). On the downside, user stories narrow the scope to what a user needs. They overlook the other two players of the game – the organization and the investors. How to bring all three perspectives nicely together and how to embed requirements in a BigPicture initiative or project?

While this article touches on gathering requirements, BigPicture is even better at planning/scheduling them and tracking their progress.

Back to the point – how to set off with requirements in BigPicture? To name your requirements properly is half the battle.

How to formulate requirements?

  1. Ideally, in a value-oriented way; second to that in a feature-oriented way. Only as a last resort, a requirement could spell a turnkey solution.
  2. Add business constraints and investors’ requirements to what the client expects.
  3. Qualitative requirements – level of satisfaction, profit margin (margin > 30%) – are as important as functional ones (product has to have…).
  4. Formulate requirements with an active speech.

Good examples are:

As a homeowner, I want to enjoy the dust-free floor, so that I have an extra hour weekly for the family, by vacuuming every four weeks.

The new bicycle product line shall rank #1 in the next year “Cycling News” market review so that we cut marketing expenses in half over the next five years.

We aim at a 30% net margin by 2025 so that investors see shares double and dividend yield exceeds 8% for pre-2022 investors.

Requirements vs. tasks

Requirements’ reason to be is to connect high-level company goals with low-level “to do” tasks. As a rule of thumb, a functional requirement (user story, the product has to have…) typically becomes a task at some point. You plan it on an agile board or you schedule it on a timeline. On the contrary, a qualitative requirement (satisfaction, margin) remains a requirement during the whole project, at best gets converted to a milestone.

Another rule of thumb: in classic project management requirements and the schedule are separate worlds – congress and senate so to speak. Based on the requirements a detailed schedule with its tasks gets created. In the agile world, on the other hand, the two worlds mingle together. Requirements simply go to the backlog, once an initiative gets approval.

Are requirements always needed? Are they necessary in each and every project? Think of requirements as lighthouses or beacons during longer journeys (projects) so that the must-haves do not get lost along the way. Requirements protect a project or product against tempting opportunities that will likely pop up en route; but who lead astray.

How to gather and trace requirements in BigPicture?

Let’s have a look at several approaches to requirements in BigPicture. The first one is the Large Scale Scrum (LeSS) approach. Adapt it to your needs even if you are far from adopting LeSS.

LeSS promotes something that is called ‘requirement areas’ – practically large backlogs. But instead of tasks, the backlog consists of requirements. As seen in figure 2 there are both value-oriented requirements (‘As a user I want…’) and feature-spelling requirements (‘There must be…’). If you expanded the bottom ‘Security settings’ epic, you would even notice yet other requirements, such as ‘As an admin…’. Actually, you can, by accessing the BigPicture demo instance, from which the screenshot comes.

LeSS Rquirement Area in Jira Big Picture

Figure 2. A requirements-oriented backlog according to LeSS. Good for non-LeSS organizations, too.

What is the workflow?

  1. Start gathering requirements. Enter them within the Scope module of BigPicture.
  2. [optional] As seen in figure 2 in the top right corner, the Scope module was renamed ‘Backlog’. You need BigPicture Enterprise to be able to complete this optional step.
  3. Attach Jira tasks or Basic tasks to requirements, as we are about to do in figure 2.
  4. Track the progress by keeping an eye on the ‘Status’ column, especially its top row.
  5. [optional] Switch to the Gantt module to schedule the requirements on the timeline.

Again, you can be involved in whatever project or product management methodology to be able to use this requirement-centric approach. But clearly, product managers will like this workflow more than project managers. Also, it is suitable for agile environments more than for those facing deadlines.

Specific, detailed requirements

If you deal with numerous, detailed, elaborate project requirements, try to include them in a Jira task’s Description field, as evident in figure 3. The critical point of this approach is to add the Description column to your Gantt view so that tasks having requirements draw attention.

Tracking requirements in Jira issue detail view

Figure 3. Tracing requirements entered into a Jira task’s Description field.

Workflow:

  1. Right-click a task > Edit
  2. Enter requirements into the ‘Description’ field.
  3. [optional] Ask your Jira admin to disable the field for certain users so that requirements don’t get deleted in action.
  4. Add the ‘Description’ column to your Gantt view.
  5. [optional] If you are in an agile environment you can add the requirements-containing Jira field to a task’s card in the Board module. See figure 4

Agile requirements in board

Figure 4. Tracking requirements in an agile environment by using the BigPicture Board module. Just add, say, the ‘Description’ field to the card layout. You can also track requirements in the Board’s backlog, by adding the ‘Description’ field as a column. Reveal the backlog by clicking the ‘Infobar’ to the right.

Business constraints and requirements of investors

So far, we have touched users’ requirements, those translating to product specifications. What about profound, sustained, multiannual requirements, such as requirements relating to profit margins, market position, brand recognition, or satisfying the investors?

The ‘Continue’ option, available in BigPicture’s Roadmap, comes in handy.

Requirements in Roadmap

Figure 5. Note how the ‘BPV-36 Gather requirements…’ group in BigPicture Roadmap extends beyond the ‘Software development’ phase to the ‘Deployment’ phase, thanks to the ‘Continue’.

Workflow:

  1. Expand ‘Main objectives’ area above teams’ areas. Gather requirements in a tree by using the ‘Add associated work’, as seen in figure 5.
  2. Click ‘Continue’ to make the meticulously built requirements list visible to everybody during future project phases, product increments, sprints, etc.
  3. Note in figure 5, how we “extended” the requirements into the ‘Deployment’ stage.
Clashing business and client requirements

In the last scenario, we will try to deal with an overabundance of requirements. When clients’ requirements clash with business constraints and investors’ desires, how do we choose the “winning” ones?

The heatmap matrix in BigPicture might lend a helping hand.

Requirements heatmap

Figure 6. Heatmap shows that the ‘Long-term survival’ requirement (bottom right) is critically important to both clients, the business, and shareholders.

Workflow:

  1. Get your BigPicture admin involved. Employ BigPicture’s Risks module, rename its axes ‘Clients’ and ‘Business & Shareholders’. Go to App configuration > Modules > Risks to do that.
  2. [optional] Having BigPicture Enterprise, you can also relabel the ‘Risks’ module to ‘Requirements’, for instance, as is the case in figure 6.
  3. Weigh requirements against each other by positioning requirements representing Jira tasks in the heatmap matrix.
Conclusion

Requirements can take many forms – short, long, value-oriented, feature-oriented, various stakeholders’ points of view. BigPicture lets you manage requirements in various ways, no matter if you are in a waterfall, agile, or hybrid environment, doing project management or product management.