Use cases and user stories are both excellent techniques for understanding what a user needs from a product. While both have a similar purpose, use cases and user stories are not meant to be used interchangeably. That is why it’s important for a business analyst to understand the difference.
The older of the two techniques is the use case, which captures usage scenarios. In other words, a use case documents how an individual uses a product to accomplish something of value. This technique works well for projects where functional requirements and usage scenarios must be – and can be – specified upfront. However, what if you can’t know the requirements upfront?
In a user story, the user and what they need the product to accomplish is also specified, but in contrast to use cases, at a much higher level.
Recognizing which technique is best suited to your situation is the key.
Addressing security requirements from the early phases of software development is the most cost-effective way of preventing security defects. Most security requirements fall under the scope of Non-Functional Requirements (NFRs).
As many practitioners have discovered, addressing security and other NFRs in agile projects is challenging for two reasons:
- Mapping NFRs to feature-driven user stories is not trivial.
- Security controls suffer from lack of visibility. Agile processes tend to bias development teams towards building features that visibly enhance the customer’s experience or fix defects.
This article goes into a bit more detail than usual….and could really help you see how you could do this in your projects.
Listen to a great Q&A Session on the Scaled Agile Framework™ answered by the Scaled Agile Partner team of Dean Leffingwell, Drew Jemilo and Colin O’Neill who are the founders of SAFe. They have been using the framework to scale Agile at clients like BMC, John Deer -while leveraging Scrum, Kanban and XP practices. They explain how you too can leverage SAFe at your organizatino as well.
Questions discussed include:
- Provide an example of how Agile was successfully scaled, size of org, and keys to your success
- Pricing models prevalent in the industry of large Agile transformations
- How to use estimations to build up roadmaps
- Delivering on time without imposing due dates on teams
- Managing teams that are not co-located or even in the same timezone (offshore resources)
- How SAFe enhances quality
- How can scaled Agile be used effectiely with limited resources
- What is the role of PMO and Project Manager in the Scaled Agile Framework?
- and much more….
SPEAKERS: Dean Leffingwell – entrepreneur, executive, author and consulting methodologist who provides agile transformation consulting services to large software enterprises. Dean was the chief methodologist to Rally Software where he focused on the application of agile development methods to large scale software development. Dean also served as Sr. Vice President to Rational Software (now IBM’s Rational Division), where his responsibilities included development and commercialization of the Rational Unified Process (RUP), ClearQuest, RequisitePro and the company’s methodology and product training courses. Dean is the author of several books, Agile Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise ; Scaling Software Agility: Best Practices for Large Enterprises , and Managing Software Requirements: First and Second Editions.
Drew Jemilo has over 20 years of experience using Agile, Lean, and traditional methodologies in companies ranging from lean startups to global corporations. He has worked in the US and Europe applying technical and leadership experience in Agile program and portfolio management, change management, organizational design, coaching, and training. He has worked with Dean Leffingwell on a large global client to synchronize distributed teams in the US, India and Eastern and Western Europe, with a significant number of mostly independent, yet necessarily cooperative, Agile Release Trains.
Colin O’Neill has been a successful IT consultant for 26 years. He has led and coached numerous organizations in enterprise Agile and Unified Process (UP) systems development and integration efforts, business process re-engineering and improvement, requirements definition, data modeling, object modeling, enterprise architecture, risk management, quality assurance, testing, change & configuration management, system deployment, training, and mentoring. Colin has worked hands-on in every lifecycle phase and discipline. He is known for quickly increasing technical organization efficiency and speeding product delivery.
PDU: 1 *** PDU info is provided in recording ***
In Dean Leffingwell’s recent webinar on scaling Lean|Agile development, he introduced the Scaled Agile Framework (SAFe) <click here for Dean’s recording>. SAFe is a public-facing set of practices which have been used to successfully scale Lean|Agile development to hundreds — and even thousands — of practitioners at companies like BMC Corporation and John Deere.
You will gain these valuable insights as we cover the following topics…
- What are best practices for writing team-based User Stories and non-functional Agile requirements?
- How do these scale to the program and portfolio levels?
- How can you work more strategically with upper management to achieve the highest business value for your company and customers?
by Dean Leffingwell
Are you tired of the myth that Scrum, XP and Kanban do not scale to the needs of the larger software enterprise? Are you tired of the ideologies that prevent your enterprise from even trying to apply them? If the answer to either of the above is yes, this presentation is for you.
In this presentation, Dean Leffingwell will finally dispel these myths and ideologies by describing the Scaled Agile Framework™, a public-facing set of practices which have been used to successfully scale Lean|Agile development to hundreds—and even thousands—of practitioners at companies like BMC Corporation, John Deere and others.
He’ll describe five key scaling mechanisms:
• SCALING VALUE: Not everything is a User Story
• SCALING DESIGN: Complex systems require intentional architecture.
• SCALING TEAM AND TIMEBOX: Aligning teams to a common mission with the Agile Release Train
• SCALING PORTFOLIO MANAGEMENT: Addressing legacy mindsets
• SCALING LEADERSHIP: Your enterprise can be no leaner than your executives thinking.
He reminds us that a non-functional requirement is a requirement that is more about the state of being of the system than about one specific thing the system does. And yes, they can be written as user stories.
Non-functional requirements often have to do with performance, correctness, maintainability, interoperability, portability, and so on. They are often called the “-ilities” of a system because so many end in “ility.”
The challenge with estimating non-functional requirements is that there are really two costs.
- The cost of initial compliance
- The cost of ongoing compliance.
To see these two costs at work – Let’s consider an example
March 25, 2011 (11-12pm PST)
Building and maintaining a Product Backlog can be a time-consuming effort. Though the Product Owner has final say in the prioritization, a good product backlog is a result of a combined effort of the Product Owner, Scrum team, ScrumMaster and stakeholders.
In this webinar you will learn techniques and ideas for the entire lifecycle of backlog management and how each of the Scrum roles, as well as stakeholders, can contribute to its overall effectiveness.
November 30, 2010 (9-10 am PST, 12-1 pm EST)
Portfolio Prioritization is a critical aspect of project work. In this interactive session, serious gaming expert Luke Hohmann will present the Innovation Games Prune the Product (Portfolio) Tree and Buy a Feature (Project) — two new approaches to prioritizing project portfolios.
Based on principles and learning’s from cognitive psychology and organizational behavior, these collaborative, serious games, enable small, co-located teams, or larger, distributed teams, to efficiently prioritize project portfolios.
SPEAKER: Luke Hohmann is the Founder and CEO of The Innovation Games Company, the leading provider of serious games that enable organizations to solve complex problems through online and in-person collaborative play. The author of three books, Luke’s playfully diverse background of life experiences has uniquely prepared him to design and produce serious games. Luke graduated magna cum laude with a B.S.E. in computer engineering and an M.S.E. in computer science and engineering from the University of Michigan. In addition to data structures and artificial intelligence, he studied cognitive psychology and organizational behavior. He is also a former National Junior Pairs Figure Skating Champion, as well as a certified aerobics instructor. In his spare time, Luke likes roughhousing with his four kids and his wife’s cooking. He also enjoys long runs in the Santa Cruz mountains to burn off his wife’s cooking. Luke’s a bit of an old school Silicon Valley entrepreneur. Instead of building a company to flip, he’s building a company to change the world. You can join him by playing games at Games for Democracy.
Misconceptions abound about how agile projects analyze and develop requirements. In practice, requirements are the basis for planning, developing and delivering agile projects.
Agile requirements are congruent– they combine to form a sound and sensible union that drives successful delivery of business value.
.YOU WILL LEARN:
- The agile method of developing requirements and how ‘traditional’ requirements practices are adapted on agile projects
- The value of requirements analysis on agile projects
- Ways in which requirement form the basis for planning on agile projects
- How effective agile teams collaborate around requirements
SPEAKER: Ellen Gottesdiener, Principal Consultant and Founder of EBG Consulting, Inc., helps business and technical teams collaborate to define and deliver products customers value and needs. Ellen is an internationally recognized facilitator, coach, trainer, author, speaker, and expert on requirements development, product chartering, retrospectives, agile requirements, and collaborative workshops.
She is the author of two acclaimed books (Requirements by Collaboration and The Software Requirements Memory Jogger), Ellen speaks at industry conferences; writes articles, blogs, and tweets; and is an IIBA (BABOK®) expert reviewer and contributor to the (in progress) agile-BABOK addendum.
Should we add “agile requirements” to the list? Does agile development fit in with traditional requirements practices? And if so, how?
Once More into the Breach
Traditionally, defining requirements involves careful analysis and documentation and checking and rechecking for understanding. It’s a disciplined approach backed by documentation, including models and specifications. For many organizations, this means weeks or months of analysis, minimal cross-team collaboration, and reams of documentation.
In contrast, agile practices—Lean, Scrum, XP, FDD, Crystal, and so on—involve understanding small slices of requirements and developing them with an eye toward using tests as truth. You confirm customers’ needs by showing them delivered snippets of software.
But agile projects still produce requirements and documentation, and they involve plenty of analysis. On the best agile projects, requirements practices combine discipline, rigor, and analysis with speed, adaptation, and collaboration. Because software development is a knotty “wicked problem” with evolving requirements, using iterative and agile practices is not only common sense but also economically desirable.
Indeed, agile requirements drive identifying and delivering value during agile planning, development, and delivery.
Agile teams base product requirements on their business value—for example, boosting revenue, cutting costs, improving services, complying with regulatory constraints, and meeting market goals. If you’re agile, it means that you focus on value and jettison anything in the product or process that’s not valuable.