DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Non-Traditional Project Planning
  • Sprint Goals: How to Write, Manage, and Achieve
  • Compatibility Testing: Checklists and Crucial Things You Need to Know About It
  • Conducting Sprint Retrospective Meetings

Trending

  • Unleashing the Power of Microservices With Spring Cloud
  • What Technical Skills Can You Expect To Gain From a DevOps Course Syllabus?
  • Graph Databases: Unleashing the Power of Relationships
  • Using Open Source for Data Integration and Automated Synchronizations
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. The Role of Specifications in Agile

The Role of Specifications in Agile

It's commonly said that everyone does Agile differently. In my experience, it's also common to do basically whatever you want and call it Agile. It can be useful to occasionally reset and examine what canonical Agile recommends.

Chase Seibert user avatar by
Chase Seibert
·
Updated Nov. 13, 15 · Tutorial
Like (2)
Save
Tweet
Share
8.16K Views

Join the DZone community and get the full member experience.

Join For Free

It's commonly said that everyone does Agile differently. In my experience, it's also common to do basically whatever you want and call it Agile. It can be useful to occasionally reset and examine what canonical Agile recommends. For software specifications, it's pretty simple. Do just enough, no more.

Why do we need specifications at all?

A software requirements specification (SRS) is a description of a software system to be developed, laying out functional and non-functional requirements, and may include a set of use cases that describe interactions the users will have with the software. - Wikipedia

Historically, specifications have been used to communicate to the customer (be it an internal or external customer) what will be built. Agile is built on the principle that this is actually not in the best interest of the customer. Why?

  • Low effort specifications will have all parties making critical assumptions.
  • High effort specifications take a lot of time - and will necessarily be wrong in big ways.
  • Scope can and should change as we learn more about the problem.

In Agile, we build in short sprints. Documentation need only be created for the next sprint, or perhaps one additional sprint. This is known as - "Just in time Documentation"

Self-directed Agile Teams

Agile artefacts such as technical spikes and development iterations mean that high-level requirements can be considered sufficient at project initiation. - Ryan Hewitt

For agile teams, specifications exist so that the team knows what they need to build. Because we are committing only to one sprint at a time, we have no need to project long-term dates that would necessitate a full specification. What documentation does the team need to get started? A highly detailed specification for just that first sprint.

agile

An agile team is composed of a product manager, a designer and one or more developers. This team must be empowered to design and implement their vision of a solution. A specification is definitely NOT for feedback or sign-off prior to building.

How does the team know to build the right thing?

Agile requirements, on the other hand, depend on a shared understanding of the customer that is shared between the product owner, designer, and the development team. That shared understanding and empathy for the target customer unlocks hidden bandwidth for product owners. They can focus on higher-level requirements and leave implementation details to the development team, who is fully equipped to do so – again, because of that shared understanding. - Dan Radigan, Senior Agile Evangelist, Atlassian

User stories are the form that specifications take. Each user story is created in advance and placed in a backlog, but only the small set of the very next stories are flesh out in detail. Then, the level of detail is very high. Designs are included at this stage, and so are detailed descriptions of fine grained behavior like validation, individual errors messages, etc.

Though the PM owns the user story, the team itself generates the detail through a processes called grooming. User empathy is critical - while PM and design naturally represent the customer in the design process, the entire team needs to understand the customer motivation and pain points.

In the end, the team may very well not build the right thing. This is where feedback comes in - at the end of a sprint, once working software is produced and shown to the customer.

When to Get Feedback

Working software over comprehensive documentation - The Agile Manifesto

In Agile, feedback is given based on working software, not specifications. The team commits to delivering and demoing working software every sprint. These demos are where feedback is generated. I've often been surprised when customers don't really know what they want until they see it.


I'm currently working at NerdWallet, a startup in San Francisco trying to bring clarity to all of life's financial decisions. We're hiring like crazy. Hit me up on Twitter, I would love to talk.

agile Sprint (software development) Software system

Published at DZone with permission of Chase Seibert, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Non-Traditional Project Planning
  • Sprint Goals: How to Write, Manage, and Achieve
  • Compatibility Testing: Checklists and Crucial Things You Need to Know About It
  • Conducting Sprint Retrospective Meetings

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: