O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
Polarion Software®

Requirements gathering in Agile
development: a practical experience
Stefano Rizzo
VP Strategy and Busi...
• Our Company
Polarion Software

In pills…

– Founded in 2004, shipped first release in 2005
• Target Markets: Requirement (RM) and Appl...
Polarion Software

Where?

• HQ
– Stuttgart, D
• Software Development Labs
– Prague, CZ
– Stuttgart, D
– Ukraine
– Russia
...
• Our needs
Why Scrum?

The promise

– Shorten time to release
• …and ensure releases

– Transparency to management/customers
• …and r...
But Scrum…

Known Issues

– Has proven its benefits in small projects
• Our main project is a huge one, lasting since 2004...
• So, Scrum…
Scrum in Polarion Software

When?

We moved to Scrum from a traditional Development
process 4 years ago

Polarion Software...
Scrum in Polarion Software

How?

• Polarion’s Iterative development has short iterations
• 2 weeks, with meetings at the ...
Scrum in Polarion Software

Backlogs

• Product Backlog items
• User Stories, described in a way that at least the idea be...
Scrum in Polarion Software

Our backlogs

Every Backlog has an owner
Backlog owners “play the user” into Sprint meetings

...
Scrum in Polarion Software

Polarion Software®

Project progress

www.polarion.com
• Requirements?
Requirements elicitation

User story

• The requirements elicitation process creates user stories
– The planning entity fo...
Requirements and Scrum

User stories

• The most difficult and critical job is to produce a good
backlog of User Stories.
...
Requirements elicitation

Road to user stories

• So, provided that we cannot invite all our users to our
meetings, we hav...
User stories from…

User Demand Management

• A user demand

Polarion Software®

www.polarion.com
User stories from…

Strategy meetings

• Strategy meetings drive innovation
– Input to strategy meetings
• Corporate missi...
User stories from…

Surveys

• Customers are requested to participate in on-line
surveys
– Participate-and-win strategy
– ...
User stories

Quality

• Ensuring the quality of user stories is critical
– Scrum works well with good user stories
– The ...
• Lessons learned
Scrum is good in…

Benefits

• Frequent and tangible results
– Short iterations with visible improvements
• Easy control o...
Scrum needs…

Implications

• In order to run Scrum effectively you must consider to:
– Keep iterations as short as possib...
Requirements and Scrum

Your job

• If you gather requirements for a SCRUM team you must
consider that:
– You are part of ...
• Questions?
• Thank you

stefano.rizzo@polarion.com
Próximos SlideShares
Carregando em…5
×

Requirements gathering in agile development a practical experience

1.989 visualizações

Publicada em

My own 6+ years experience as PM in gathering requirements for a big Scrum project

Publicada em: Tecnologia, Negócios
  • Seja o primeiro a comentar

Requirements gathering in agile development a practical experience

  1. 1. Polarion Software® Requirements gathering in Agile development: a practical experience Stefano Rizzo VP Strategy and Business Development Swiss Requirements Day, 22.6.2011
  2. 2. • Our Company
  3. 3. Polarion Software In pills… – Founded in 2004, shipped first release in 2005 • Target Markets: Requirement (RM) and Application Lifecycle Management (ALM) Web and SaaS based • Target Users: Product Managers, Requirement Engineers, QA, Testers, Business Analysts, Developers, Project Managers – 3 product lines • Commercial, web based • Commercial, SaaS • Open Source tools – 750.000+ users worldwide Polarion Software® www.polarion.com
  4. 4. Polarion Software Where? • HQ – Stuttgart, D • Software Development Labs – Prague, CZ – Stuttgart, D – Ukraine – Russia • Product Managers – Italy and USA • Customers – everywhere Polarion Software® www.polarion.com
  5. 5. • Our needs
  6. 6. Why Scrum? The promise – Shorten time to release • …and ensure releases – Transparency to management/customers • …and release what’s expected – Faster reaction • to market needs • to users’ feedback • to the change – Simplify synchronization of distributed teams – Easier releasing to the market • Lower effort to stabilization, less things to test – Flexibility in prioritization, risk reduction Polarion Software® www.polarion.com
  7. 7. But Scrum… Known Issues – Has proven its benefits in small projects • Our main project is a huge one, lasting since 2004 – Frightens the board • Do we control costs and releases? – Gives power to the development team • Does it ensure traceability and accountability? – Needs the customer to be part of the team • Where will we sit 750.000 users? Polarion Software® www.polarion.com
  8. 8. • So, Scrum…
  9. 9. Scrum in Polarion Software When? We moved to Scrum from a traditional Development process 4 years ago Polarion Software® www.polarion.com
  10. 10. Scrum in Polarion Software How? • Polarion’s Iterative development has short iterations • 2 weeks, with meetings at the beginning and at the end of each iteration (called sprint in Scrum) Polarion Software® www.polarion.com
  11. 11. Scrum in Polarion Software Backlogs • Product Backlog items • User Stories, described in a way that at least the idea behind each one is clear. – “The user must be able to reset the status of an item to the original one” (pretty good user story) – “Improve the performance of the product” (bad user story) • Business value for Backlog items • Each User Story must be valuable for the user • A good prioritization is critical to ensure the success of the project – Especially when you have two thousand candidates and the ability to implement 10-12 in a iteration Polarion Software® www.polarion.com
  12. 12. Scrum in Polarion Software Our backlogs Every Backlog has an owner Backlog owners “play the user” into Sprint meetings Polarion Software® www.polarion.com
  13. 13. Scrum in Polarion Software Polarion Software® Project progress www.polarion.com
  14. 14. • Requirements?
  15. 15. Requirements elicitation User story • The requirements elicitation process creates user stories – The planning entity for the sprint is a user story. – Each user story has customer (the person who formulated the requirement) and an owner – typically a Senior Developer, who then follows the user story through the full development cycle • A user story should be: – Atomic: should be implemented in one sprint – Self-explaining: describes the need in user’s words – Valuable: its benefits should be readily understood Polarion Software® www.polarion.com
  16. 16. Requirements and Scrum User stories • The most difficult and critical job is to produce a good backlog of User Stories. – Altogether they cover the full product • very hard to ensure – They are flat and independent on each other! • Team work on the stories one after another – They must be small • so you need to break “big” features into smaller sub stories – thinking about user scenario for every small piece Polarion Software® www.polarion.com
  17. 17. Requirements elicitation Road to user stories • So, provided that we cannot invite all our users to our meetings, we have Product Managers “playing the customer” • PMs derive User Stories from: – User Demand Management process • Mainly fed by Professional Services and Sales – Strategy meetings • Lot of ideas, often far from the ground… – Internal and customer surveys • “Why that button is not blue?” Polarion Software® www.polarion.com
  18. 18. User stories from… User Demand Management • A user demand Polarion Software® www.polarion.com
  19. 19. User stories from… Strategy meetings • Strategy meetings drive innovation – Input to strategy meetings • Corporate mission • ALM and RM vision • Analysis of competition – Participants • Management team – Method • Blue Ocean Strategy Polarion Software® www.polarion.com
  20. 20. User stories from… Surveys • Customers are requested to participate in on-line surveys – Participate-and-win strategy – Questions related to daily use impressions and suggestions for improvements • All Polarion employees are requested to fill their wish list – Wishes include new features and improvements – Every major release – Results are analyzed with different weights Polarion Software® www.polarion.com
  21. 21. User stories Quality • Ensuring the quality of user stories is critical – Scrum works well with good user stories – The whole approach fails if • User stories need to be discussed again and again with the author • User stories are not specific enough • User stories are not granular enough – The development team gains more power • Quality gateway to accept user stories • The development team refuse to work on unclear user stories Polarion Software® www.polarion.com
  22. 22. • Lessons learned
  23. 23. Scrum is good in… Benefits • Frequent and tangible results – Short iterations with visible improvements • Easy control over development activities – But this needs discipline and tools • Transparent project progress – But this needs a good backlog (i.e. good User Stories) Polarion Software® www.polarion.com
  24. 24. Scrum needs… Implications • In order to run Scrum effectively you must consider to: – Keep iterations as short as possible (2 weeks max) – Invest in product management/requirement spec. • Definition of user stories is the critical bottleneck • Innovation happens outside the development team – Keep high motivation in the development team • In “traditional” development, developers are requested to invent a lot – with the shortfall that results could be different from what expected • With Scrum developers are told what to do precisely, so they could be frustrated Polarion Software® www.polarion.com
  25. 25. Requirements and Scrum Your job • If you gather requirements for a SCRUM team you must consider that: – You are part of the Development Team, with them you share success and blame • User stories are discussed every day, not just at the beginning of the development • You must continuously try to find answers, examples, clarifications for developers – Your requirements must be decomposed into good user stories • Finding out a requirement is still the key, but taking it to its real essence is not an easy task Polarion Software® www.polarion.com
  26. 26. • Questions?
  27. 27. • Thank you stefano.rizzo@polarion.com

×