Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Building the right product or building the product right?

No description
by

Amy Johnston

on 11 January 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Building the right product or building the product right?

Building the right product or building the product right?
Key Benefits
Building the product right
and
building the right product
are two different things.
Deriving Scope from Goals
Successful teams collaborate to design a solution
Introduction to SBE
An Approach to specifying software systems using executable tests that both validate the system and also provide the documentation for the system at the same time.
Refining Specifications
Living Documentation
SBE creates
Living Documentation
in the form of
executable test scenarios
Questions
The design provided a better and cheaper solution than what the customer asked for simply by asking, "Why?"
Understand the
'WHY'
and
'WHO'
Understand What Outputs the Business Users Expect
Have the team provide the 'I want' part of the user stories
Ask how something would be useful
Ask for an alternative solution
Try Big, All - Team Workshops
Three Amigos
Domain requires frequent clarification
Pair-writing
Mature products
Team Review of Specifications
Informal Conversations
Business stakeholders are readily available
Specifying Collaboratively
Starting out with SBE
Illustrating Using Examples
Examples are easier for all stakeholders to understand than abstracts!
Examples should be precise and complete
Examples should be realistic and easy to understand
Find ways to ensure that you have complete and correct information
Illustrating nonfunctional requirements
Performance
UI requirements
Response time
Security
Specifications should be:

About functionality, not design
Precise and testable
In a shared language
Self explanatory
Focused
Why is automation important?
How many points does it have?
Let's Build It!
Automation Discussion
It becomes difficult and time consuming to manually run all the checks within short iterations
Author's Poll Results
In software projects …there is a single correct answer in similar situations: the one that the business people thought of.
Specifications should
not
be:
Testing scripts
Specification By Example
Automate as many as possible
It is the acceptance tests and supporting documentation
Specifications should be:
Full transcript