Requirements gathering in agile development a practical experience
•
2 likes•2,690 views
My own 6+ years experience as PM in gathering requirements for a big Scrum project
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Requirements gathering in agile development a practical experience
Similar to Requirements gathering in agile development a practical experience (20)
Recently uploaded
Recently uploaded (20)
Requirements gathering in agile development a practical experience
- 1. Polarion Software® Requirements gathering in Agile development: a practical experience Stefano Rizzo VP Strategy and Business Development Swiss Requirements Day, 22.6.2011
- 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. 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. • Our needs
- 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. 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. • So, Scrum…
- 9. Scrum in Polarion Software When? We moved to Scrum from a traditional Development process 4 years ago Polarion Software® www.polarion.com
- 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. 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. 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. Scrum in Polarion Software Polarion Software® Project progress www.polarion.com
- 14. • Requirements?
- 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. 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. 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. User stories from… User Demand Management • A user demand Polarion Software® www.polarion.com
- 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. 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. 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
- 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. 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. 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. • Questions?
Editor's Notes
- Customers love these statements in the Agile Manifesto:Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.On the other hand, developers very much like the following:Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Agile processes promote sustainable development. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams.
- The development core team has 7 senior developers (participating in meetings) each managing 2-3 juniors.The Iteration length is set to 2 weeks, which we have thus far found optimal for a team the size of Polarion’s R&D department – i.e. several teams with 3 to 10 team members.
- In our development, it’s hard to start with single Product Backlog, as there are too many stakeholders, who want to prioritize own things first. E.g. there is the Professional Services team, who help customers onsite and who have their own usability wish list. There is also the Support team, which calls attention to common problems, and of course there is Senior Management, who want to see some big features, but they can’t specify exactly what is expected, just a general direction, like “we need XXX Integration, because our competitors also have it”.In our case backlogs are mostly populated from the following sources:Feature Backlog is populated by Product Management, who collect requests from the Customer Demand list (where PM identifies priority from the customer perspective, business opportunities, and check if a request is customer-specific or popular among several customers), from the Professional Services Organization (PSO), from the Development Team, from Community users and so on.Usability Backlog is populated by the Product Management, PSO/sales and Development TeamProcess Backlog reflects requests concerned with how to improve productivity of internal development and provide more transparency to the management – populated by PM and Development Team.Performance Backlog is populated by the Development Team based on continuous profiling of the product and reviews of possible architectural refactoring of the product.Integrations Backlog is populated by the PSO and Development Team based on input from the customers, potential clients and opportunities for better exposure to or acceptance of Polarion ALM by the customers.QA Backlog is focused on testing activities, identification of defects that “must be fixed in next release”, etc.
- If it’s not recorded in our demand management, a demand does not existDemands are prioritized by means of $$$ and satisfaction/dissatisfaction levels (Volere and others)User demands drive improvements don’t create innovation