Skip to main content

Home/ BARE+IA Requirements Engineering Information&Business Analysis/ Group items tagged SAFe

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Peter Van der Straaten

Alistair.Cockburn.us | Why I still use use cases - 1 views

alistair.cockburn.us/Why+I+still+use+use+cases

agile use case user story uml cockburn debate

shared by Peter Van der Straaten on 25 May 12 - Cached
  • XP pretty much banned use cases, replacing them with the similar sounding “user stories”
  • Scrum did similar, using the “product backlog” instead of user stories
  • Yet as I go around projects, I keep running across organizations suffering from three particular, real, painful, and expensive problems
  • ...15 more annotations...
  • User stories and backlog items don’t give the designers a context to work from
  • don’t give the project team any sense of “completeness
  • don’t provide a good-enough mechanism for looking ahead at the difficulty of upcoming work
  • Staring at the set of extension conditions in a use case lets the analysts suss out which ones will be easy and which will be difficult, and to stage their research accordingly
  • Here 5 reasons why I still write use cases
  • The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users
  • The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do.
  • The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget
  • The use case extension scenario fragments provide answers to the many detailed, often tricky business questions
  • The full use case set shows that the investigators have throught through every user’s needs, every goal they have with respect to the system, and every business variant involved
  • how much should be written up front to get the project estimate into a safe place
  • several sticky parts for people using use cases
  • iteration/sprint lengths are so short that it is not practical to implement an entire use case in just one of them.
  • Writing good use cases (or any other requirements) requires thinking, communicating, and thinking again. It is much easier just to write user-story tags on index cards and let the project blow up later
  • We have adopted many of the concepts of Agile development—such as daily build and test, build the smallest piece of functionality that delivers value, etc.—but have retained our up-front work. It’s worked extremely well
Peter Van der Straaten

Hightech Events: Scrum - 0 views

www.runbysoftware.com/...scrum

scrum Agile SAFe 2015 SPIder

shared by Peter Van der Straaten on 08 Jul 15 - No Cached
  • Scrum works very fine within small teams, adding new functionality in an incremental way. But how to transform traditional developers into a scrum way of working and how to align the multiple teams? How to maintain piles of legacy code? And how to go about solving the specific issues the high tech industry has with Agile? The session ‘Scrum is not enough!’ will give an overview of these challenges and presents best practices to address them.
  • Peter Van der Straaten on 08 Jul 15
     
    Inclusief presentaties
Peter Van der Straaten

The beginner's guide to BDD (behaviour-driven development) - 0 views

inviqa.com/bdd-guide

BDD requirements requirements analysis TDD EPO agile

shared by Peter Van der Straaten on 20 May 21 - No Cached
  • to support the ability for systems to change, we should be able to safely make big changes (supported by automated scenarios), as well as the small ones (supported by automated object specifications).
  • Impact mapping
  • mind mapping
  • ...19 more annotations...
  • business goal, one or more actors, one or more impacts and one or more ways to support or prevent these impacts
  • You always start with the business goal; it is your map’s root node. You then grow the map out from the goal by first identifying all the actors (e.g. the customer or the team) that could help or prevent the project from achieving the goal. Each actor could have multiple ways to help or hinder achieving the goal, we call these impacts. The last layer of an impact map defines what the project or delivery team can do in order to support or prevent particular impacts from happening, and this is the layer where your software options come into play.
  • In BDD we use Cynefin to identify which features require the most attention
  • Value and complexity analysis
  • reuse
  • outsource
  • Cynefin to make strategic planning decisions based on value/complexity analysis
  • Planning in examples
  • Usage-centered design
  • Ubiquitous language
  • eliminate the cost of translation
  • borrowed from DDD (Domain Driven Design)
  • 'Given, describes the initial context for the example'When' describes the action that the actor in the system or stakeholder performs'Then' describes the expected outcome of that action
  • Introducing the three amigos
  • no single person has the full answer to the problem
  • business person, a developer and a tester.
  • Development through examples
  • The BDD loops
  • How we use it
Peter Van der Straaten

Product Owner - Scaled Agile Framework - 0 views

www.scaledagileframework.com/product-owner

scrum SAFe product owner requirements engineering business analysis qbest

shared by Peter Van der Straaten on 17 Mar 22 - No Cached
  • For most enterprises moving to Agile, this is a new and critical role, typically translating into a full-time job, requiring one PO to support each Agile team (or, at most, two teams). This role has significant relationships and responsibilities outside the local team, including working with Product Management, Customers, Business Owners, and other stakeholders
  • Without the right number of people in the right roles, bottlenecks will severely limit velocity.
1 - 5 of 5
Showing 20▼ items per page