0
Technology Supported Requirement Handling and Estimation<br />Kjetil Moløkken-Østvold – Conceptos Consulting<br />NDC2010,...
Aboutthe speaker: Kjetil Moløkken-Østvold<br />Senior Partner at Conceptos Consulting<br />Academic and research backgroun...
Today’s message<br />
Contents<br />Requirement handling and estimation<br />The case: Lindorff<br />Problem<br />Solution<br />Results<br />Con...
Requirement handling and estimation<br />
Software Project Overruns<br />About 70-80% of all projects encounter effort (cost) overruns¹ <br />The average magnitude ...
Is requirement handling important?<br />Requirement processes demand<br />Structure and a long-term perspective<br />Close...
Requirement handling<br />Changed and new requirements are perceived as the customers' most frequent contribution to overr...
Frequent communication<br />Previous studies have found communication to be important for project success<br />Frequent co...
Contact frequency and overruns<br />A Kruskal-Wallis test for difference results in p=0.023<br />The corresponding size of...
The requirement pyramid ©<br />Project managers<br />Customers<br />End-users<br />Interaction designers<br />Developers a...
Agile development and estimation?<br />”-the concept of an overrun is not one typically found in agile development process...
Main challenge<br />It appears as if many books, papers and tutorials in the Agile community assumes:<br />A customer with...
Estimating Agile projects<br />Agile projects are hardly immune to overruns, delays and bad business decisions based on po...
Combination of estimates may reduce overruns<br />Several studies have found that combination of estimates may reduce over...
Why combine estimates?<br />Obtain knowledge from various sources<br />Avoid extreme decisions<br />Synchronize perception...
Pitfalls when combining estimates<br />Passive participants<br />Depending on chosen method: political pressure (groupthin...
Some methods for combining estimates<br />
Delivery (release) estimated with Wideband Delhi<br />A release for NextLevel<br />Six estimators representing development...
Estimation should be an integrated part of the requirement process<br />Estimation, prioritization and planning of require...
Project processes<br />A study found that effort overruns differed significantly depending on project process¹<br />Sequen...
The easy part when implementing agile processes<br />Having some meetings while not sitting down<br />Moving yellow notes ...
The hard part when implementing agile processes<br />Developing and prioritizing requirements<br />Providing (accurate) es...
The hard part is even harder in a distributed environment<br />
The case: Lindorff<br />Lindorff Group is a leading outsourced receivables management company in Europe and on a global ba...
NextLevel Project<br />Purpose of project<br />To deliver a new .NET GUI on an existing debt collection application<br />R...
NextLevel Project<br />Distributed participants<br />Developers in Oslo and Bø<br />Testers and business developers in Osl...
Internal improvement study Q4 – 2007, findings:<br />Poor routines for communicating and prioritizing requirements<br />Ef...
Describing, refining, prioritizing and communicating requirements is difficult for business people<br />Understanding, est...
Problem: inefficient communication<br />
Solution<br /><ul><li>Implement a flexible sharing regime for requirements, prioritization and estimates
Lindorff joined a project financed by Innovation Norway
Main development partner was Symphonical</li></li></ul><li>About Symphonical<br />Symphonical is a webtool that takes you ...
Example features used by Lindorff<br />
Live<br />Allows for synchronized collaborative work<br />Actions performed by one person is shown in real-time to others ...
Sharing<br />Share one or more information containers (notes) with collaborators<br />Used in<br />Requirement specificati...
Voting/estimation<br />Used for estimating requirements/user stories in collaboration<br />Used in advance of the develope...
Voting/estimation (cont.)<br />
Conversations<br />A history of in-context discussions, replaces mail etc.<br />Used through out the requirement process, ...
Template <br />A default text on notes (requirements/user stories)<br />Used<br />in order to make sure the requirements a...
Tool<br />Reuse settings/templates<br />Used in order to be able to reuse structures and default text on notes in later pr...
Results<br />
<ul><li>Lindorff improved on all studied areas
Respondents provided ratings (1-5, 1=best) </li></ul>Main results (two years after)<br /><ul><li>Effort overrun (perceived...
All respondents (IT and business) reported that use of Symphonical had greatly improved how requirements were specified, r...
Estimation
About half reported that Symphonical had improved the estimation process
The other half reported no discernible impact from Symphonical by itself (though it could have played a role along with ot...
Responses to a large extend depended on company role, with business perceiving most value</li></li></ul><li>Respondent quo...
Upcoming SlideShare
Loading in...5
×

Technology supported requirement handling an estimation

664

Published on

Lindorff Group is a leading outsourced receivables management company in Europe, and one of the leading on a global basis. For the past three–four years, they have increasingly adopted agile practices, especially in a large scale project converting and improving an old system written in Powerhouse to new .Net–technology.

The results from adopting agile practices have been mostly positive, however, there were challenging issues related to requirement handling and estimation that needed attention. In 2008, Lindorff joined a project with Symphonical funded by Innovation Norway. The purpose of the project was to develop software for requirements handling, estimation and knowledge management for the Symphonical platform. Symphonical is a flexible web–based collaboration platform, where users can brainstorm, plan, organize and coordinate any process.

This talk presents results from a case study detailing the challenges faced by Lindorff as they simultaneously adopted agile practices and introduced a new system for requirement handling and estimation. According to the respondents of the case study, Lindorff appears to have improved on two of the main points of concern presented in the 2007 study: requirement handling and estimation. Many users report that the introduction of agile methods and the platform Symphonical has improved the quality of important work processes. Furthermore, they report that the introduction of Symphonical has provided a framework for structured discussions regarding individual requirements, which helps maintaining the focus of IT projects. Furthermore, the flexible sharing regime where one can easily share information to external participants improves the effectiveness and efficiency of collaboration with all project contributors.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
664
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Kjetil
  • Hans
  • KjetilMulig noe mer tekst?Gode diskusjoner Bevissthet hos kundesideIdentifikasjon av feil/mangler I spesifikasjon
  • Kjetil
  • 1 – Svært god2 – God3 – Middels 4 – Dårlig 5 – Svært dårligX – Vet ikke
  • Transcript of "Technology supported requirement handling an estimation"

    1. 1. Technology Supported Requirement Handling and Estimation<br />Kjetil Moløkken-Østvold – Conceptos Consulting<br />NDC2010, 16.-18. June, Oslo<br />
    2. 2. Aboutthe speaker: Kjetil Moløkken-Østvold<br />Senior Partner at Conceptos Consulting<br />Academic and research background<br />PostDoc and Assistant Director at Simula Research Laboratory (Norway)<br />MSc (Siv.Ing.) and PhD from the University of Oslo (Norway)<br />Published 23 papers on various topics, including estimation, project management, agile, collaboration, communication, contracts etc.<br />Recent commercial projects<br />External quality assurance and consulting for several large public sector projects (>500 MNOK)<br />Process improvement for financial and telecom companies<br />
    3. 3. Today’s message<br />
    4. 4. Contents<br />Requirement handling and estimation<br />The case: Lindorff<br />Problem<br />Solution<br />Results<br />Conclusion<br />
    5. 5. Requirement handling and estimation<br />
    6. 6. Software Project Overruns<br />About 70-80% of all projects encounter effort (cost) overruns¹ <br />The average magnitude of effort overruns is 30-40%<br />Similar results for schedule overruns<br />No apparent change the past 30-40 years<br />¹Moløkken-Østvold, Jørgensen, Tanilkan, Gallis, Lien and Hove. A Survey on Software Estimation in the Norwegian Industry, In 10th International Software Metrics Symposium (METRICS 2004)<br />
    7. 7. Is requirement handling important?<br />Requirement processes demand<br />Structure and a long-term perspective<br />Close collaboration with customers/users<br />Should you have <br />A big up-front requirement process, <br />Only one for each iteration, or<br />A combination? <br />Many have trouble with requirement processes in agile development<br />
    8. 8. Requirement handling<br />Changed and new requirements are perceived as the customers' most frequent contribution to overruns¹<br />Overruns are prevented by the availability of competent customers and capable decision makers<br />Avoid the influence of irrelevant and misleading information<br />¹ S. Grimstad, M. Jørgensen, and K. J. Moløkken-Østvold. The Clients' Impact on Effort Estimation Accuracy in Software Development Projects, In: 11th IEEE International Software Metrics Symposium (METRICS 2005), Como, Italy, September 19-22, pp. 3, IEEE, 0 ed.. 0, 2005.<br />
    9. 9. Frequent communication<br />Previous studies have found communication to be important for project success<br />Frequent communication can be used to prioritize features, set focus on bug-fixing or include more functionality (Beck and Fowler, Planning Extreme Programming, 2001)<br />Motivated in part by Cockburn¹, we explored the frequency of communication between the contractor and the customer<br />¹ Cockburn, "The End of Software Engineering and the Start of Economic-Cooperative Gaming," ComSIS, 2004.<br />
    10. 10. Contact frequency and overruns<br />A Kruskal-Wallis test for difference results in p=0.023<br />The corresponding size of effect is d=1.25, indicating a large size of effect <br />
    11. 11. The requirement pyramid ©<br />Project managers<br />Customers<br />End-users<br />Interaction designers<br />Developers and testers<br />Precision<br />Communication costs<br />Abstraction<br />Increases<br />Levels<br />Roles<br />Characteristics<br />
    12. 12. Agile development and estimation?<br />”-the concept of an overrun is not one typically found in agile development processes themselves, and precision estimation up front is not typically seen as a priority.” <br />- Comment from anonymousreviewer, Agile 2007, researchtrack.<br />
    13. 13. Main challenge<br />It appears as if many books, papers and tutorials in the Agile community assumes:<br />A customer with no need for budget or schedule when starting a project<br />No need for long term planning within the development team(s)<br />That minor estimates derived as you go (e.g. for sprints) are sufficient<br />
    14. 14. Estimating Agile projects<br />Agile projects are hardly immune to overruns, delays and bad business decisions based on poor estimates<br />“Planning Poker” or similar techniques for estimating sprints or releases are important, but not sufficient<br />It is often necessary to provide a relatively accurate estimate of total project delivery schedule and costs at en early stage, due to:<br />Bidding<br />Budgeting<br />Staffing<br />Scheduling<br />Release planning<br />All of the above…<br />
    15. 15. Combination of estimates may reduce overruns<br />Several studies have found that combination of estimates may reduce over-optimism and overruns¹<br />True for both contract work and in-house development<br />Combination in itself may be more important than the method chosen<br />¹ K. J. Moløkken-Østvold, N. C. Haugen, and H. C. Benestad. Using Planning Poker for Combining Expert Estimates in Software Projects , Journal of Systems and Software 81(12):2106-2117, 2008.<br />
    16. 16. Why combine estimates?<br />Obtain knowledge from various sources<br />Avoid extreme decisions<br />Synchronize perceptions about estimates and work at hand<br />Create ownership of estimates<br />Remove irrelevant information (if using moderator)<br />Introduce a ”devil’s advocate”<br />
    17. 17. Pitfalls when combining estimates<br />Passive participants<br />Depending on chosen method: political pressure (groupthink)<br />Requires good moderators and experts<br />Time-consuming and costly (?)<br />
    18. 18. Some methods for combining estimates<br />
    19. 19. Delivery (release) estimated with Wideband Delhi<br />A release for NextLevel<br />Six estimators representing development and business<br />Release was broken down to a set of requirements (about 30 elements to estimate)<br />
    20. 20. Estimation should be an integrated part of the requirement process<br />Estimation, prioritization and planning of requirements provides new information<br />Several roles should be involved in the estimation<br />Consider involving the customer as well<br />Estimation should happen at several ”levels” (ref. the pyramid) in order to verify and triangulate<br />
    21. 21. Project processes<br />A study found that effort overruns differed significantly depending on project process¹<br />Sequential (waterfall): 55%<br />Flexible (agile, iterative): 24%<br />Projects with a flexible process ranked higher on:<br />Good requirements<br />Good collaboration between developers and business/customer<br />¹ Moløkken-Østvold and Jørgensen, "A Comparison of Software Project Overruns“, IEEE Transactions on Software Engineering, 2004.<br />
    22. 22. The easy part when implementing agile processes<br />Having some meetings while not sitting down<br />Moving yellow notes around a whiteboard<br />Using strange job titles <br />
    23. 23. The hard part when implementing agile processes<br />Developing and prioritizing requirements<br />Providing (accurate) estimates<br />Collaborating between developers and customers<br />
    24. 24. The hard part is even harder in a distributed environment<br />
    25. 25. The case: Lindorff<br />Lindorff Group is a leading outsourced receivables management company in Europe and on a global basis<br />Lindorff has approximately 2200 employees <br />Offices in Denmark, Estonia, Finland, Latvia, Lithuania, Germany, the Netherlands, Norway, Spain, Russia and Sweden<br />
    26. 26. NextLevel Project<br />Purpose of project<br />To deliver a new .NET GUI on an existing debt collection application<br />Re-write business logic from Powerhouse to PL/SQL and .NET <br />
    27. 27. NextLevel Project<br />Distributed participants<br />Developers in Oslo and Bø<br />Testers and business developers in Oslo, Røyken and Trondheim<br />Users/customers in Røyken, Oslo, Trondheim and other locations<br />
    28. 28. Internal improvement study Q4 – 2007, findings:<br />Poor routines for communicating and prioritizing requirements<br />Effort overruns (about 25%)<br />Internal collaboration rated as average<br />
    29. 29. Describing, refining, prioritizing and communicating requirements is difficult for business people<br />Understanding, estimating and developing requirements is difficult for software developers<br />
    30. 30. Problem: inefficient communication<br />
    31. 31. Solution<br /><ul><li>Implement a flexible sharing regime for requirements, prioritization and estimates
    32. 32. Lindorff joined a project financed by Innovation Norway
    33. 33. Main development partner was Symphonical</li></li></ul><li>About Symphonical<br />Symphonical is a webtool that takes you from idea to action<br />It incorporates document handling, group collaboration and simple task tracking using digital post-it notes (information containers) on walls<br />Cloud based (Amazon) since 2008<br />Spin-off from Simula Research Laboratory<br />
    34. 34. Example features used by Lindorff<br />
    35. 35. Live<br />Allows for synchronized collaborative work<br />Actions performed by one person is shown in real-time to others logged in<br />Used in<br />Requirement workshops<br />Requirement reviews<br />Used when the meeting is held in more than one location <br />
    36. 36. Sharing<br />Share one or more information containers (notes) with collaborators<br />Used in<br />Requirement specification<br />Requirement quality assurance<br />Used to get input from resources outside the project<br />Sporadic contributors<br />
    37. 37. Voting/estimation<br />Used for estimating requirements/user stories in collaboration<br />Used in advance of the developers estimation meeting, i.e. the first estimation iteration <br />Used in the estimation meeting to administrate estimation iteration 2 (and if needed; iteration 3)<br />Can also be used to prioritize requirements etc.<br />
    38. 38. Voting/estimation (cont.)<br />
    39. 39. Conversations<br />A history of in-context discussions, replaces mail etc.<br />Used through out the requirement process, from the initial workshop to the final quality assurance<br />Helps keep track of the evolution of the requirements<br />
    40. 40. Template <br />A default text on notes (requirements/user stories)<br />Used<br />in order to make sure the requirements are expressed in a format that makes sense to the developers<br />to ”force” the requirement handlers to provide mandatory information<br />
    41. 41. Tool<br />Reuse settings/templates<br />Used in order to be able to reuse structures and default text on notes in later projects/deliveries<br />Supports the use of the chosen methodology<br />
    42. 42. Results<br />
    43. 43. <ul><li>Lindorff improved on all studied areas
    44. 44. Respondents provided ratings (1-5, 1=best) </li></ul>Main results (two years after)<br /><ul><li>Effort overrun (perceived) was reduced from an average of 25% to 12%</li></li></ul><li>Responses from Lindorff<br /><ul><li>Requirement handling
    45. 45. All respondents (IT and business) reported that use of Symphonical had greatly improved how requirements were specified, refined and communicated
    46. 46. Estimation
    47. 47. About half reported that Symphonical had improved the estimation process
    48. 48. The other half reported no discernible impact from Symphonical by itself (though it could have played a role along with other improvements)
    49. 49. Responses to a large extend depended on company role, with business perceiving most value</li></li></ul><li>Respondent quotes<br />“I perceive [the change to Symphonical] as positive [...] better than Excel [...] having every requirement as a use case is good. Structure, retrievability and traceability is much better than in Word and Excel.”<br />“It is easier to get input from more people now [...] it is easier to concentrate on one single requirement at a time.”<br />”…Previously, onestudied and estimated in meetings. Now it is possible to prepare, estimate and think [...] one can view average values and there is traceability.”<br />
    50. 50. Conclusion<br />
    51. 51. Lessons learned<br />Analyze your situation regarding quality of requirements and magnitude of effort overruns<br />Get rid of static documents (Word, Excel etc.) shared via email and informal communication (calls, notes on desk etc.)<br />Implement a web-based collaboration platform<br />
    52. 52. The future of work?<br />
    53. 53. Q&A<br />
    54. 54. Thank you!<br />Contact information:<br />Presentation: http://www.conceptos.no/<br />Email:<br />Please visit our stand here at NDC!<br />This research project was<br />Funded by Innovation Norway<br />Conducted in collaboration with Dr. Kjetil Kristensen, founder and Principal Consultant of Kristensen Consulting<br />Caveat Emptor: the author of this presentation is a member of the board of directors at Symphonical, and has ownership interests in the company<br />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×