Agile Archives

Tag Archive for: Agile

In this blog post, we summarize our Whitepaper titled “Critical Alignment for Security, Safety, & Product Teams in Automotive Development”. Click HERE to read the full Whitepaper.

Critical Alignment for Security, Safety, & Product Teams in Automotive Development

As automotive product development becomes increasingly complex with multiple standards for compliance, alignment between different teams is more critical than ever. Yet in many organizations, specialized teams such as cybersecurity, safety, product development, and even project management work separately. In other cases, teams may be dispersed across organizations or geographies, making alignment even more challenging. Is collaboration and alignment even possible within these complex environments?

How Safety and Security Teams Become Siloed

On the safety side, the standard for functional safety in automotive, ISO 26262, has been around since 2011, and the safety work has been around even longer than that. For original equipment manufacturers (OEMs), tier ones, and some tier twos, the organizational competency, processes, tools, and culture of safety are quite mature. Enter the cybersecurity side, which is a new discipline in automotive development. Cybersecurity has new standards, audits, and assessment requirements, and requirements are coming very rapidly from OEMs and tier ones worldwide. Cybersecurity teams are still going through training. The processes for doing product development according to standards like ISO 21434 are new or still in development. The discipline itself is new and transforming out of IT security.

The differences between the two disciplines lead to siloed teams of specialists even though both of those standards and both of those disciplines require automotive V-model development, with strict requirements for documentation, quality, and compliance with the V-model.

As organizations strive to align these disciplines along with product development, they typically begin cross-communication by sharing vehicle-level risk analysis and handing safety or cybersecurity top-level requirements to product development teams. While this is a good step towards effective collaboration, a lack of transparency and the ability to fully collaborate across teams and tools still present significant problems and add unnecessary risk. Both safety and security standards are risk-based. ISO 26262 addresses systematic and random hardware faults which mitigate the risk of harm to persons due to defects in the system or from hardware wearing out prematurely. On the cybersecurity side, the risk of harm to persons is measured in terms of safety, financial, operational, or privacy impact and addresses the possibility or risk of an attack to critical system assets by a bad actor.

RELATED WEBINAR: Effectively Managing Cybersecurity in Jama Connect® for Automotive and Semiconductor Industries

The controls or the mitigations for these types of risks might result in conflicting requirements — for example, how to handle a communication channel such as vehicle to network (V2N) or vehicle to device (V2D). In this example, the safety and security teams must work together, along with product development, to solve requirements discrepancies and build an integrated system that works cohesively.

Of course, automotive manufacturers and consumers have dealt with safety issues, recalls, crashes, and fatalities for years. Now that most automotive systems include cellular, Bluetooth, and other ways to connect into the vehicle, development teams and manufacturers need to consider and address cybersecurity issues. The surge in cybersecurity threats stemming from connected cars and the expanding software content in vehicles has prompted the industry to swiftly embrace the new ISO 21434 cybersecurity standard. This is evident in scenarios ranging from managing vehicle fleets to halting production lines and posing safety hazards.

Effective communication plays a critical role in tying together disciplines of safety, security, and product development together. Safety analyses and threat analyses can’t happen in a vacuum. Teams must coordinate, communicate, and align to achieve a comprehensive development picture that fulfills every team’s requirements. In fact, both ISO 21434 and ISO 26262 require teams to establish communication channels between safety, security, and other disciplines such as quality.

If not identified early, conflicting requirements often result in costly rework. Typically, the safety and security teams each write their own requirements with limited interaction at different times in the product development cycle. Sometimes, cybersecurity requirements come late and conflict with safety requirements, causing rework late in the cycle after software has already been developed, tested, and integrated. That rework results in unpleasant surprises in schedules, retests, and additional costs.

RELATED: The Impact of ISO 26262 on Automotive Development

How the Right Collaboration Tools can Improve Alignment

One trend driving teams toward better alignment and collaboration is the continual increasing complexity of software in the vehicles. Standards such as R155 and R156 are driving cybersecurity adoption as well as software-supplied services into the car, ADAS, and AI. Continuous updates are driving unsustainable growth in the amount of software in the vehicle.

The rising threat of cyberattacks, exacerbated by the integration of additional software into vehicles, is a key driver of cybersecurity adoption. The ISO 21434 standard seeks to address these new cybersecurity requirements, but because it’s so new, the communication channels are not yet well established.

The OEMs are rushing to support cybersecurity, which throws cybersecurity players right into the middle of a massive increase in software development. The OEMs are bringing software in-house and building Agile software factories, and tier ones and tier twos are racing to comply.

This diagram depicts the difficulty of adopting Agile software in automotive. In some cases, it’s like running into a compliance wall.

Some OEMs and tier ones are responding by picking and choosing the pieces of Agile they would like to implement. But these organizations are finding that it’s difficult to develop embedded automotive software that’s compliant with these standards in an Agile way, such as running Scrum with mini V-models.

Alignment and visibility when rapidly developing software — and in a compliant way — is critical to bringing together product development, safety, security, and other teams. When Agile methodologies such as Scrum are implemented, there is a risk of accruing technical debt if safety, security, and product development are not harmonized, often due to the demanding documentation needs and heightened quality standards for stories and epics.

TO DOWNLOAD THIS WHITEPAPER IN ITS ENTIRETY, VISIT:
Critical Alignment for Security, Safety, & Product Teams in Automotive Development

In this blog, we recap the “Managing Mission Critical Requirements in an Agile Environment” webinar.

Over the last two decades, Agile has been demonstrated to be a powerful approach to software and systems development. It has taken on a number of representations but there are features that most representations share – namely “flexibility” when dealing with requirements.

The common theme is for the user community (or the representative of the user community) to state in very broad terms what user functionality would be beneficial and then leave the details (and often the priorities) to the software “whiz”.

This is seen by many as antithetical to mission or safety-critical systems. Systems where the operational characteristics must be well understood to prevent loss of life or mission failure when the product performs differently than expected. In a similar manner, the system must be reliable since it is essential for mission success or human safety.

In this webinar, attendees will learn more about how:

Agile can deliver cost and schedule benefits when developing mission or safety-critical software
Exploiting Agile requires adapting approaches often assumed for Agile – especially when it comes to requirements management
When appropriately applied, Agile can give you a product that is more reliable/dependable than classical methods

Below is an abbreviated transcript and a recording of our webinar.

Managing Mission Critical Requirements in an Agile Environment

Cary Bryczek: Welcome to our virtual user group’s keynote. Today, I’m joined by Mr. Kenneth Hebert, he’s the Chief Technical Director at AFuzion, Inc. Mr. Kenneth Hebert is a 40-year veteran of safety-critical software engineering, including over 35 years as a system safety software project and process leader manager with a Ph.D., MS, BS in Computer Science, extensive experience in the safety systems and architectural design of real-time safety-critical defense and other military and private sector applications, also a registered Agile Scrum master and CMMI software process expert. He has extensive experience in systems software development methodologies ranging from Waterfall to Agile and experience with developing and deploying processes that integrate concepts embodied in DOD, NASA, ISO, AS, and FAA standards, as well as development frameworks, such as CMMI and Lean Six Sigma. He is Lean Six Sigma certified, a certified Scrum Master, and SCAMPI lead appraiser trained. I am delighted for Mr. Hebert to come and deliver our keynote. Welcome and thank you, Kenneth. Please take it away.

Related: Jama Connect® Solution for IBM® DOORS®

Kenneth Hebert: Good morning. It’s certainly a pleasure to be here. What we’re going to talk about this morning is a little bit about Agile and requirements, and hopefully, we have a few thoughts that you can take with you and use as you go forward as a part of this conference. So this is the agenda I’d like to cover. We’d like to talk a little bit about what Agile is for those of you that might not have been familiar with that term or that approach to development a little bit about whether or not it’s different and in what ways is different. And then bringing that back into the fold of requirements and requirements management and how things fit together in that realm.

So again, hopefully, these thoughts will give you a few things to chew on and you can go forward and use them as a part of this conference and everything. So in any event, what is Agile? Well, Agile means a lot of things to a lot of different people. Actually, Agile was coined back in the early 2000s. It began with something called the Agile Manifesto and basically it was a document put together by a series of thought leaders in the software community. And at a time when, if you think about what was going on in the early 2000, and late ’90s, we had a number of standards coming out that were driving to what they perceived to be a heavyweight process.

Related: Better Product Development: Five Tips to Achieve Live Traceability™

Kenneth Hebert: Standards that called for delineation of what had to be done, exactly how it was going to be done. The CMMI was being introduced. Mill standard 498 had been installed and was being used 12207 was being worked on. NASA was putting together its standards for how it expected software to be done in development with respect to space systems. So all of them had seen several common themes, and those were those involved in essentially heavily evaluating and systematically approaching the software development process and as a part of that requirement, requirements management.

So this was in some ways a revolt or at least looking at where the pendulum was, and a claim by these leaders that let’s not lose sight of what we’re doing. Let’s realize that our objective here is to solve a problem and let’s get back to what’s really important. So what you’ve seen over the last two decades, is that Agile has become a significant influence in the development community, the software, and systems development communities. What you’ve seen is it’s been applied in a number of different contexts. It actually can be, because it really isn’t a development methodology as much as it is a set of guiding principles. And so we want to talk a little bit about what those were so that we can kind of have a common discussion as we look at what those areas, those principles, what you’ll see are some common themes in all these areas.

And that is it’s built around the notion that you have that a team is used to build a product. That team has a shared purpose. It’s typically a multidisciplinary team. It has all the skills and knowledge needed to get the job done successfully. It’s a cooperating group. They work together in order to achieve the objective and they blend their skills. They don’t operate as a group of individuals. They operate as a team. Much like if you think of a football team where everyone is operating together in order to achieve a touchdown and to advance the ball down the field. No individual may be the perfect running back or the perfect lineman or the perfect quarterback, but as a group, they overcome each other’s deficiencies in order to achieve a common goal. And that’s really what you want to see in an Agile environment.

To watch the full webinar, visit: Managing Mission Critical Requirements in an Agile Environment

In the quest for a successful product development process, there are any number of steps that could go wrong or lead to release delays or cost overruns. Few, however, are as vital to a good outcome as the requirements gathering process.

The requirements gathering process is central to a timely and efficient release of a product that fulfills expected deliverables. Unfortunately, this important step is too often rushed, condensed, or truncated. When all of the relevant stakeholders aren’t consulted for input, the requirements document won’t include everything necessary for a successful product, and the process may be doomed to failure before design even begins.

To help you gather the right requirements from the right people, Jama has assembled this step-by-step guide to the requirements gathering process.

A Step-By-Step Guide to the Requirements Gathering Process

If you’ve waited until project kick-off to start gathering requirements, you may have already waited too long. Requirements gathering should begin as soon as possible—even before the official beginning of the project, if possible.

Phase One: Requirements Elicitation

The initial phase of requirements gathering is elicitation, which is just a process of collecting all of the top-requirements from all relevant stakeholders through a series of sessions, meetings, surveys, interviews, or other means. The elicitation process can be broken down into four steps:

1: Establish stakeholders. The very first step in requirements gathering is figuring out whose input to include in the process. You can split stakeholders into three basic groups:

- Internal stakeholders: These are the people inside the company or on the development team who have a direct interest in positive outcomes. Internal stakeholders can include the project sponsor, managers, SMEs, and others.
- Technical stakeholders: Technical stakeholders are the teams and leaders responsible for developing and implementing the project or product. This group may include developers, testers, solution architects, and other support teams.
- External stakeholders: This group will have an interest in the outcome of the project, but will not necessarily be directly involved in development. External stakeholders may include compliance and regulatory groups, business analysts, or customers and end users.

2: Define initial scope of the project. Defining project scope is key to avoiding scope creep along the way. While it’s important to recognize that the scope may change after requirements gathering sessions, defining the initial scope can help keep the project from getting out of control early on.

3: Set up requirements gathering sessions. Once you’ve established the various stakeholders, start holding sessions to gather requirements. These meetings could include internal or external stakeholders or even a combination of both. For a successful session, follow these guidelines:

- Establish a clear agenda ahead of time. Write out the main points to be covered in the meeting, including any specific questions or development items for which you need to write requirements.
- Take notes. Never assume that someone else is taking notes! Write your notes under each agenda item so that you start grouping requirements. For example, if you know that a particular integration will be necessary, make notes under that heading on your agenda to keep those requirements together. Review your notes immediately after your meetings and send to internal teams to make sure everything is captured in one place. Save your notes to a shared folder for the entire team.
- Start creating tasks. After notes are completed, use them to start creating tasks and action items and defining deliverables. Set up future meetings as needed to capture additional action items and requirements.

4: Get creative. Initial requirements gathering sessions may be focused more around technical stakeholders or business analysts, but be sure to include time to gather input from creative team members—marketing, design, and others. It’s also good to include sessions with end users, sales team members, and others who can offer input on what features and benefits the final product should include.

For a deep dive into requirements gathering techniques, visit: 11 Requirements Gathering Techniques for Agile Product Teams

Phase Two: Requirements Documentation

In the documentation phase, the development team organizes input in the form of user stories, functional decompositions, feature descriptions, and the like. We break this phase into three steps:

Write the Marketing Requirement Document (MRD). The MRD is the document that expresses a customer’s needs or wants in a final product from the development team. This document will help define customers and their pain points, identify competitors, and establish business needs and desired business outcomes.
Revise scope, if necessary. This isn’t an opportunity to completely redefine the project concept or scope, but rather a modification step that takes into consideration all of the requirements gathering sessions. The point of this step is simply to make sure the scope is defined as completely as possible to avoid future scope creep.
Write the Product Requirement Document (PRD). Or collect the requirements in some other format that your team or organization has agreed to use—a spreadsheet, a database, or a requirements management tool like Jama Connect. This document should include relevant insights from the MRD and other supporting early notes. It should also integrate user stories, feature descriptions, functional and non-functional requirements, etc. It should have four main components: purpose, features, release criteria, and timeline.

Phase Three: Submit for Review

Once you’ve conducted multiple requirements gathering sessions and completed the initial documentation, it’s time for review.

Confirm requirements with stakeholders. Involve as many of the original stakeholders as possible. Ask them to review the requirements as defined in documentation. Are the requirements clear to all parties? Did the product development team miss any important requirements? Revise any requirements that are unclear to all parties. Be sure to get sign-off on individual requirements by relevant stakeholders.
Conduct prototyping and testing. Wherever possible, conduct initial prototyping and testing on a working model of your specification. Perform feasibility, usability, and product concept testing. This step should be conducted at the same time as the previous step so that results can be shared with stakeholders.
Prioritize requirements. Once requirements are clarified and signed off, the team should prioritize them with as specificity as possible. More than just noting whether a requirement is a “must have” or “nice to have,” prioritization should also involve ranking each requirement within the higher categories.

There is much room for overlap between these phases and steps, and it may feel overwhelming to undertake the entire requirement gathering process before any design or development begins. However, spending the time to conduct a thorough requirements gathering process can save time and money and create a much higher probability of success for your project.

Common Pitfalls of Requirement Gathering

Even when a thorough process is undertaken, teams can encounter challenges and pitfalls along the way that risk introducing delays into the project development process.

Making assumptions or not clarifying requirements. When faced with a long list of stakeholders or requirements gathering sessions, it’s tempting to make assumptions. Take the time to clarify, ask more specific questions, and get as much detail as possible. And be sure to be as specific as possible in your confirmation process!
Focusing on HOW instead of WHAT. Requirements should address WHAT a product MUST do (the functional requirements) and WHAT constraints it will have on how it achieves that functionality (the non-functional requirements). Don’t let assumptions about tools, features, techniques, implementation, or other development concerns influence how you gather and write requirements. Just listen to the needs of stakeholders and write the requirements to those needs.
Failing to adequately consult stakeholders. This pitfall could take several forms. It may mean not conducting enough sessions at the beginning of the process, or it could mean not adequately confirming requirements before beginning design and development. Be sure to get a thorough review and sign-off of all requirements before moving on to the next phase. One way to do this is with a good requirement management (RM) tool such as Jama Connect. With a requirements management tool, everyone has access to the same information, and notes and other feedback can be attached directly to requirements for traceability purposes.

Requirements Gathering for Agile Development

While the requirements gathering process outlined above is ideal for many projects, Agile teams have different needs, and an extensive requirement gathering process could interfere with their results. Agile teams expect to work fast, and scrums and sprints are typically just a few weeks, at most.

For Agile teams, a robust requirement management tool can streamline requirements gathering and management without sacrificing results. With a tool like Jama Connect, teams have transparency and access to requirements at all times, allowing easy annotation and clear traceability. Requirements management products encourage collaboration throughout the ALM product development process and offer clear advantages over static tools such as spreadsheets or simple documents.

Comprehensive requirements gathering is the key to a successful product development process. By clearly defining requirements and scope up front and getting sign-off from all stakeholders before full design begins, teams will have a much clearer path to product development success. While it’s no replacement for a requirements management solution like Jama Connect, which automates Live Traceability™, download this project requirements template to make things simpler.

In this post, we look at non-functional requirements are tracked by agile product teams and how they impact the product development cycle.

Imagine that you’re in the market for a new car. As you shop, you have a couple of non-negotiable features or attributes in mind, such as saving destinations within the car’s built-in GPS navigation system or that the car must be black. Although you may consider these to be “must-have” features, they would be considered non-functional requirements tied to the user experience.

What are Non-Function Requirements (NFR)?

Non-functional requirements are global constraints on a software system e.g., development costs, operational costs, performance, reliability, maintainability, portability, robustness etc.

A requirement that does not relate to functionality, but to attributes such as reliability, efficiency, usability, maintainability, and portability.

In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.

Non-functional requirements may be found in adverbs or modifying clauses, such as “The system prints invoices quickly” or “The system prints invoices *with confidentiality.”

Software has non-functional requirements that are essential to creating a positive experience for the user. And if you miss the mark on these requirements, you may have scheduling delays, budget setbacks and unsatisfied clients.

A project that lacks non-functional requirements may also lack clarity, which can result in vague project scope and a disconnect between the designer and client expectations.

Non-functional requirements bridge the gap between what developers believe customers want and what customers really want.

One study found that 60 to 80 percent of the cost of software development involves rework. And when the non-functional requirements are done well, you may eliminate 50 to 80 percent of product defects.

So, now that we’ve defined non-functional requirements, how do you integrate them effectively into your product development process?

Non-functional requirements focus on the “ilities” of the product

The “ilities” of a product include quality, reliability, manufacturability, usability, serviceability, upgradeability, etc. See SEAri MIT for more information.

Non-functional requirements focus on the user experience. A non-functional requirement is a statement defining a system quality, constraint, or external interface. For example, you might want to build a system that can manage expansion in the future. But saying so isn’t enough. You need to be specific. Instead, you might define that as “building a system that can manage at least 50,000 users over the next 24 months, so customers don’t experience the frustration of system crashes.”

Additionally, a non-functional requirement may:

Follow any legal or adherence rules.
Define quality attributes of the software.
Ensure performance in key areas such as reliability, availability, scalability, and more.
Focus on the user experience so the system is easy to operate and the risk for potential rework is minimized.

Just as with car shopping, not everyone needs the same features to make their user experience great. You might want warming seats in a new car, but somebody else might want a third row of seats. So, the non-functional requirements that you define for your project will vary based on client expectations. A list of potential categories, however, can give you a starting point to consider which non-functional requirements need to be on your list.

What are the different types of non-functional requirements?

Think about non-functional requirements as buckets that hold attributes important to the user experience. Remember, it’s not what a product will do (which are its functional requirements), but it’s what a project will be.

If you have selected the right buckets and measured the right things, then you can feel confident that you’re handing over a product that will meet customer expectations – because you’ve clearly defined these expectations up front. Everyone is on the same page, which is even further enhanced when you centralize your requirements management, which we’ll touch on shortly.

For now, let’s look at some of the potential categories for non-functional requirements:

Performance and scalability. What are the required response times, benchmark specifications, and other attributes related to performance? How fast does the system provide results, and how will the performance change with higher workloads?
Operating constraints. Operating constraints may include any required software requirements, system requirements, and run-time constraints that need to be considered in product development.
Platform constraints. Most projects include some sort of platform constraints. Clearly define these upfront.
Modifiability. How much effort is required to make changes to the software? Defining this upfront can help the customer better plan for any potential changes.
Portability requirements and capability. How difficult will it be to move the software to a different platform? What hardware and operating system does the software run on? Does it conflict with other processes or applications within these environments? Clearly define these elements.
Reliability. How often does the software fail? Outline any consequence of software failure and strategies for detecting errors, plans for error correction, and more.
Security. Security focuses on the requirements for protecting the system and data. How much time and effort does it take to break into the system, and how can you mitigate these exposures?
Usability. Usability is focused on the user experience. How difficult is it to learn and operate the system, and how can you improve any potential uses?
Legal. There may be legal issues around data privacy, intellectual property rights and more.

Categories vary by project, yet some common categories include availability, capacity, reliability and security. Using a few of the more common ones to start and then expanding to other areas can help you build a template for new product development projects.

Functional vs. non-functional requirements: What’s the difference?

Attributes of Functions vs Nonfunctional Requirements

Functional requirements are focused on how the software needs to perform or the desired behavior of the system. For example, if a specific condition is met, a system will send a new user a welcome email. A functional requirement is focused on what the system does when a requirement is met. Other functional requirements might involve business rules, reporting requirements, audit tracking, and more.

A non-functional requirement focuses on properties and characteristics of the product that are generally passive. Non-functional requirements are focused on attributes such as privacy, portability, reliability, stability, and more.

What is a non-functional requirements document?

Non-functional requirements are one component of the software requirements specification document (SRS document). This document focuses on what the software is expected to do and how it’s expected to perform. It also addresses what is required in terms of functionality from a user perspective.

The SRS documents include a few sections, such as:

Overview of the system. The overview includes high-level details about the system. Any useful terms are defined upfront in a glossary-like format.
General description. This section outlines any assumptions about the project and the overarching vision or theme.
Specific requirements. This section is where the functional and non-functional requirements are included.

If you haven’t written an SRS document before, or if you want to improve on your existing document, check out examples as a starting point. These also provide inspiration for how non-functional requirements examples flow into the entire document.

What templates exist for tracking and managing a non-functional requirement?

Software and hardware teams collaborate throughout the entire development process as they define functional and non-functional requirements. However, this collaboration becomes problematic when teams use different tools. Centralizing requirements management allows you to save time, align more effectively, and ensure the quality and compliance of product development. Using a single solution enables you to effectively:

Experience a single source of truth. A single source of truth offers greater visibility throughout the entire product development cycle.
Benefit from real-time iteration. Working within a requirements management platform that has visibility and communication across all development teams enables more informed decisions and improves collaboration abilities.
Enjoy stronger visualization. You can more effectively visualize how tests trackback to requirements, resulting in higher quality and compliance.
Reuse validation requirements. Reuse validated requirements to quickly replicate features across products.

Centralizing requirements management allows you to build stronger and more effective non-functional requirements, which improves product development. A single source of truth empowers you to connect data, conversations, and decisions – all within a single system.

The result is that you can collaborate and communicate critical pieces of information around product development, resulting in less rework, fewer missed deadlines and happier clients.

See How Jama Connect Streamlines Tracking and Tracing Requirements.

On May 20th, BeanStock Ventures brought together a panel of medical device software experts, including Jama Software VP of Customer Success, Clay Moore, to bridge the gaps between modern software development and regulatory requirements.

The topic: Agile development. The panel explored if Agile could maintain its adaptive nature and still being complaint under guidance provided by TIR45, a recognized consensus standard by the FDA.

During the webinar, the panel de-mystifies the idea that Agile development lacks the proper controls for producing safe and effective software and that the regulation is burdensome. They cover a range of exciting topics along the way.

The panel explores key issues about Agile and TIR45, including:

How the Agile Manifesto is trying to encourage us to find the proper balance – not get rid of the discipline and documentation that we need, but to find a better balance between that and developing useful working products.
How the development of a foundation of requirements is the single most important design control activity because requirements which form the design input establish the basis for performing tasks and validation of design.
How TIR45 helps address common misconceptions about applying Agile at scale with multiple teams, and the need for documentation.

The panel also offers insights to topical Agile questions like:

How does one balance employing Agile methodology alongside predicting project timing accuracy?

“Perhaps predictability isn’t the right word. A better word might be adaptability, that we can respond to changes in a healthy way that still meets the business needs to be predictable.”

-Kelly Weyrauch, Owner, Agile Quality Systems

Does Agile help you tame change?

“Don’t try to tame change. Embrace it as a natural thing of doing product development in today’s rapidly changing world. And Agile provides mechanisms to be in control of those changes.”

– Kelly Weyrauch, Owner, Agile Quality Systems

What’s the right level of regulatory burden?

“It is generally not the regulations that bring the burden. It’s an organization’s interpretation of them. And nearly every case when I see an organization saying they have a burdensome process, it’s because they did it to themselves. They defined their process, they defined the documentation requirements, they defined the sequencing of things and the rules behind it, in a way that’s burdensome.”

– Kelly Weyrauch, Owner, Agile Quality Systems

So much more was covered in this informative session. To see what you missed, head over and watch the on-demand webinar now.

WATCH NOW

Jama Connect captures real-time feedback and decisions to give you visibility into every stage of the product development cycle, from benchmarking and monitoring team progress to enabling stronger collaboration between stakeholders.

You have a wealth of information available to you in Jama Connect, but it’s only helpful if you can find what you need when you need it. Here are three tips for finding data quickly and easily.

Search Bar

OK, you probably thought of using the search bar, but you may not be using it to its full potential.

When you search for a term like “hardware,” Jama Connect’s robust search functionality will pull up every item containing that keyword, including Word, PDF, and text attachments. Your search isn’t restricted to items with the word “hardware” in the title or description; Jama Connect will show you every item that contains the word “hardware” anywhere. This powerful functionality tends to be underused.

You can also limit your search to a specific field, like the item name, just by adding a colon to your search. “Name: Hardware” will locate all items with the word “hardware” in the document name.

Say you’re looking for something more specific, like a client’s name. If there’s only one result for your search term, Jama Connect will automatically open a window taking you to that item, so you can hit the ground running.

Note: For the next two tips, we’re assuming a certain level of familiarity with Jama. For a more granular guide to these features, start with the Jama Connect User Guide or get your questions answered in the Jama Support Community.

Find Me

Jama Connect’s Find Me feature allows you to locate the item you’re working on within the project structure, represented by the Explorer Tree. At any moment, you can get a comprehensive, integrated view of the project and see how each item fits in. The Find Me feature keeps you from missing the forest for the trees by putting the holistic vision for the project top-of-mind. At the same time, Find Me helps you orient each task you’re working on in relation to the project as a whole.

Trace View

Trace View offers live traceability within the product development cycle, showing you upstream and downstream items, missing relationships and item details in the context of relationships.

To access Trace View, select it from Projects. The items you selected in List View will appear in the Source column, with related items downstream from the source to the right and related items upstream from the source on the left. From there, you can use the blue arrows at either side of your screen to toggle upstream or down.

You can also apply filters to Trace View to see items by type — like subsystem requirement, verification or design description.

Additionally, Jama Connect lets you save a Trace View and bookmark it on your homepage for easy access. You can save multiple views to facilitate working on or managing items in different capacities.

Finally, you can export saved Trace Views as CSV files or share them with team members by copying and sharing the URL. (Note that Trace Views cannot be made public, so the best way to give every team member who needs to see a specific upstream or downstream view is to send them the URL.)

For a deeper dive into maximizing Jama Connect, check out the Ask Jama webinar, or explore the Jama Connect User Guide, which is full of tools to plan and track progress and performance.

Better time-to-market is a priority for any development team, but it can come at the cost of accuracy and quality. There are many metrics to track progress and evaluate success in dev teams, but the following are especially crucial for those seeking to balance speed against accuracy and quality.

Cycle Time

Cycle time measures how much time is spent working on an issue – in other words, how long it takes the issue to “cycle” from one state to another (usually from open to closed). You can look at cycle time by type (how long it took a bug to go from open to closed) or by status (how long a bug sat open before it was closed).

Monitoring cycle time helps you set accurate expectations and identify bottlenecks or other pain points affecting your team. A spike in cycle time often points to a breakdown or a blockage somewhere in your process, meaning it’s time for an open conversation about what’s working and what’s not.

Release Cycle Time

This metric tracks your team’s total time per release: from the moment when a release began to when it was shipped. Tracking release cycle time can pinpoint holdups and process inefficiencies that delay delivery. Understanding release cycle time also helps you determine the accuracy of your ship dates and manage expectations around future releases.

Velocity

Velocity measures your team’s delivered value: the amount of value-added work, like features ready to test or ship, delivered during an agreed-upon time period.

Teams generally calculate velocity across three or more intervals to establish average velocity. Average velocity serves as a baseline for setting delivery expectations, understanding if your team is blocked and determining whether your process changes are working.

Your volatility is also relevant – that is, how much and how often iterations deviate from average velocity. High volatility signals that something is broken in your process or team.

Throughput

Throughput is your team’s total work output: the number of features, tasks, and bugs that are ready to ship or test within a given time period.

Usually, teams refer to last period’s throughput, but average throughput can be an especially helpful metric when it comes to capacity planning: comparing average throughput against the current workload tells you when your team might be overloaded.

Throughput helps measure your alignment with your goals. For example, if your primary goal is bug-squashing, you should expect to see plenty of defect tickets being resolved; if you’re focused on features, you should see more feature tickets than bugs. When your team’s progress is blocked, or their energies are pointed in the wrong direction, throughput drops.

Open Pull Requests

Pull requests are how developers ask their teams to review changes they’ve made to a code repository. This metric measures how many pull requests in a given repository — or across all repositories — have been opened but not closed.

Your number of open pull requests will affect your throughput and iteration flow, so keeping an eye on this number can improve your team’s delivery time.

Tracking open pull requests over time also helps you spot bottlenecks in your feature delivery process.

Work in Progress

Work in progress (WIP) is the total number of tickets or issues that your team is currently working on. Like throughput, WIP is an objective measure of a team’s speed as a present moment indicator.

Ideally, WIP remains stable over time; an increase in WIP can identify inefficiencies in your process or signal that your team is overstretched (unless you’ve added more team members, of course!).

You can also divide your WIP number by the number of contributors on your team to get a sense of average WIP per developer. This number should be as close to a 1:1 ratio as possible, since too much multitasking tends to affect the quality and accuracy of your deliverables.

Iteration Flow

Iteration flow is a visualization of the status of your tickets over time. Flow is a good description, since this metric visualizes the shift of work from one status to another as your team moves toward completion through a defined process. It measures time to delivery along with the repeatability and health of your process.

Monitoring iteration flow helps highlight breakdowns in your process and get ahead of delivery problems, and it gives everyone on your team a tool to evaluate the predictability of their work.

Difficulty of Feature Implementation

This metric reflects your team’s perception of how difficult it was to implement a particular feature. An anonymous poll every sprint that asks your team to weigh in on the challenges of implementing the most recent feature(s) is a good way to collect the qualitative data you need.

Your team’s perception of the difficulty of feature implementation can have a huge impact on product roadmap and sprint planning. This metric helps you understand when your team would benefit from additional resources or extra training – or when they are ready to tackle more challenging work.

Should we release faster?

This metric represents your team’s perception of whether the team should speed up its cadence of releases. As with difficulty of feature implementation, you’ll need qualitative data to evaluate this metric. You’ll get the best information by polling your team every month or every quarter, since this metric doesn’t tend to fluctuate as much from sprint to sprint.

How your team feels about the pace of their sprints can give you insight into velocity, throughput and overall team health, while adding crucial context to your release window accuracy metric.

To get the full story on tracking data points for development teams — including more information on how to measure them and why — download our eBook, The Essential Guide to Software Development Team Metrics.

Jama Connect allows you to create groups to manage permissions and facilitate collaboration at the project level. Groups allow you to work smarter and faster by empowering you to manage notifications, permissions, access and action for multiple users at once.

There are two types of groups:

Project groups: These groups are created in the context of a specific project and are available to that project when adding permissions.
Organization groups: These groups have no product context; they’re available to all projects in the organization.

You can name groups according to your internal structure (i.e. job title or work group), by access permission (read-only, read/write), or by role (project admin, review admin).

Jama Connect comes equipped with several pre-defined project and organization groups, such as Organization Admin, a default group with organization and project permissions.

Creating groups based on users’ roles or permissions allows you to:

Grant access and role permissions
Initiate reviews
Subscribe users to items
Notify users of changes to content or workflow

Only your organization’s Jama administrator can determine which people have access to which project. However, as a project administrator, you’re empowered to group your users in a way that makes sense for your project.

The Users tab within your project will display everyone who has any level of access to the project. (This is the list of users determined by your organization’s administrator.) To create a new group within your project, click Add Group in the upper right. You can change who’s in the group, manage the group subscriptions, change the group name or even remove the group. For stakeholders who work on the project in different capacities, you can also add users to multiple groups.

Groups aren’t just an easy way to manage multiple users’ permissions at once (although that’s certainly useful!). Groups enable collaboration, provide transparency and visibility across the product development cycle and allow for greater security when required.

Groups are where the organizational administration of Jama Connect really overlaps with project management within the platform. We recommend identifying high-level groups at the organizational level that are managed by the administrator, like a read access group, and then letting project managers handle the group permissions, notifications and actions within each project.

For more on creating and editing groups, check out the Ask Jama webinar, or explore the Jama Connect User Guide.

While every project is different, the same key components for project managers often dictate success or failure: creating realistic expectations, negotiating stakeholder priorities and accurately capturing the full scope of work.

In a perfect world, these things would all happen seamlessly and every project would finish early and under-budget. But we all know that most often that’s just not the case.

Whether you’re new to project management or a seasoned pro, take heed of these seven common project management mistakes to avoid missing deadlines, going over budget and contributing to overall project failure.

Mistake #1: Not clearly defining success prior to starting the project

If one stakeholder feels strongly that launching by a particular date is the measure of success while another is solely focused on increasing market share, you’re in for a nightmare when it comes to managing priorities and expectations.

Avoid battling stakeholders by ensuring everyone has a common definition of success prior to kicking off.

Start by identifying who is most important to this project and defining their interests and expectations. This will allow you to agree on clear and measurable business goals that can be tracked and measured throughout the project lifecycle.

Mistake #2: Not defining when a product will be ready for release

In addition to defining measures of success, it’s vital to a project’s success to clearly define when a product will be finished and ready to make its debut before embarking on development.

When stakeholders have different definitions of when a product is ready to be released, you’re sure to run into tension and frustrations across the board.

To avoid this, decide what criteria will indicate whether your product is ready for release early in the process. Make sure the criteria are realistic, objectively measurable, documented and most importantly, mutually agreed upon.

Mistake #3: Making commitments you’re not sure you can keep

As a project manager, you’re no stranger to mounting pressure. With that said, one of the biggest (and easiest) mistakes a project manager can make is committing to deliverables or timelines that aren’t positively doable. The key here is to have good-faith negotiations with team members, managers and stakeholders and agree on goals that are realistically achievable.

When things inevitably change (like budget or resources) or you run into unanticipated problems, be upfront and clear as soon as you know that things have shifted.

Having these tough conversations and realigning commitments with everyone involved is the best way to avoid disappointment and frustration.

Mistake #4: Misestimating timelines

Projects never go 100% as planned. However, as a project manager, it’s your job to anticipate what might happen throughout the product development cycle (good and bad) and give your best estimated timeline.

The good news is that you’re not alone. Many commercial tools are available to help you estimate entire projects. These solutions give a spectrum of possible timelines to help you get a better idea of how things might shake out based on the project’s breadth and depth.

Mistake #5: Failing to plan for rework after a quality control activity

Speaking of misestimating timelines… many project managers make the dire mistake of not planning for additional work after a quality control activity.

While we all hope that we get it right the first time, the reality is that almost all quality control activities find needed improvements.

To stay on the safe side, great project managers always include time for rework after every single quality control event. The best part? If there isn’t any rework that needs to happen, you’ll be ahead of schedule and you’ll look like a rockstar.

Mistake #6: Failing to track progress throughout the entire project

When stakeholders ask for an update on the project, you’ll want to be a specific as possible. This is only possible if you track the progress of the project throughout the entire lifecycle. The reality is, unless you record the actual effort or time spent on each project task — and compare them to the estimates — those estimates will just be guesses.

As project managers, we sometimes give project updates that are misleadingly optimistic (see above). Remember, you can only manage a project effectively when you really know what’s done and what isn’t, what tasks are falling behind and what issues and risks still need to be tackled.

Mistake #7: Not learning from past projects

Expanding on mistake #6, another downfall for project managers is failing to conduct a project retrospective (AKA postmortem) following the completion of a project.

If you tracked your progress meticulously and thoroughly throughout the entire project, you should be able to glean some vital lessons that you can take with you into your next project. Take note of what went well, what didn’t go well, what surprised you and what you still might not understand.

This information will help guide you in your next project and allow you to create better time estimates and set realistic expectations.

As a project manager, you’re the key communication hub between team members, managers and stakeholders. The success of a project can often be directly related to a project manager’s ability to effectively manage requirements and expectations, communicate with all parties involved clearly and concisely and direct the project when adaptations need to be made.

Want to learn more about successfully managing every project? Check out our eBook “Project Management Best Practices” for 21 tips on taking the pain out of project management.

Technical debt refers to the implied cost of rework necessitated by choosing a fix that’s easy to implement now, rather than a better resolution that would take longer. In simple terms, tech debt points to the work your team will have to do in the future as a result of cutting corners today.

That said, tech debt isn’t a negative indicator across the board, and it’s impossible to avoid altogether. Sometimes taking on tech debt makes sense, like when you need to speed your time to market or account for last-minute spec changes.

Complex software that requires extensive refactoring — that is, restructuring of existing code — is particularly associated with tech debt, but refactoring is not only a response to problems with the code. Refactoring often represents an evolving understanding of a problem and the best way to solve it.

Still, it behooves teams to minimize unnecessary tech debt. In our ebook, “The Essential Guide to Software Development Team Metrics,” we dig into metrics to assess the speed, accuracy, quality and health of your team. Seven of these metrics are especially important to bear in mind when working to minimize tech debt:

Ticket churn

Also referred to as “ticket bounceback,” ticket churn is a measure of how many tickets have been moved back in progress over a period of time. Ticket churn gauges rework, so high ticket churn can indicate increasing tech debt, and is likely to impact your team’s velocity and overall product quality.

New vs. closed bugs

Track how many bugs are opened against how many are closed to find the rate at which your team clears bugs. This metric is an indicator of your overall tech debt, as well as whether your team is moving in the right direction in terms of general code quality.

Bug burndown

Development and quality assurance teams use bug burndown to understand open bugs and their projected closures based on the average bug closure rate. Teams that don’t keep a close eye on bug burndown can lose a handle on their overall product quality and take on excessive amounts of tech debt in their effort to fix bugs quickly.

Percentage of high-priority bugs

This straightforward calculation — dividing the number of current, high-priority bugs by the total number of bugs — is simply the percentage of bugs that your team has tagged as high-priority (sometimes high-severity) due to their impact on customers or the product as a whole. Tracked over time, this metric illuminates part of the story of both product quality and tech debt. An increasing trend of more high-priority bugs is often symptomatic of a team struggling with product requirements, test cases and test suites.

Code churn

Code churn reflects the number of lines of code deleted and added in the same line. It’s a measure of activity over time that highlights hotspots in your code.

With brand-new features, a lot of activity in one area isn’t a problem, but over time, code churn should diminish; if it doesn’t, you’re doing too much rework and accumulating an unnecessary amount of tech debt. High code churn can also predict a drop in quality and speed.

Code coverage

Also called test coverage, code coverage is the percentage of lines of code that are executed when running your test suite. Fundamentally, code coverage refers to how effective your test process is at producing a quality product. As a rule of thumb, coverage should be in the 80-90% range.

Code coverage doesn’t measure the inherent quality of your product; rather, it helps reveal the process your team is undertaking to achieve a quality product. Code coverage highlights breakdowns in your test process, like when new code is added but not tested.

If your code coverage percentage drops over time, devote more resources to test-driven development (TTD) and make sure untested areas are covered. A high-quality test process heads off quality issues and reduces tech debt, setting your team up to be nimbler in the future.

Frontend app response time

Frontend app response time, or the average time it takes for your pages to be available to end-users, helps your team identify when important product updates or infrastructure upgrades are necessary to keep your solutions running smoothly.

Usually monitored closely by DevOps teams, frontend app response time is critical to product success. Your product might add huge value, but users will start looking elsewhere if it’s too slow. An increase in response time often suggests rising technical debt: your short-term solutions are creating long-term problems for your customers and your team.

Get the full story on metrics for development teams: Pick up The Essential Guide to Software Development Team Metrics now.