User story estimation with agile architectures

1,276 views
1,067 views

Published on

How Agile Architecture can bring value to an Agile team? How can we use the Architecture tools to provide a better estimation?

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

No Downloads
Views
Total views
1,276
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
31
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • WHYSoftware ArchitectIssues with Agile TeamsIssue in providing ROI without an architecture in placeDeveloped this session over my experiments with teams
  • BRIEF INTRODUCTIONHow I came to Agile ArchitectureWHEN should be adopted?ALWAYS, Working with Agile Teams, less formal Architecture is required
  • WHATAgile believe that every member can cover ANY positionWe know is not possible cause it requires experience and knowledgeArchitecture can be slow and too formal, we need a more agile way of using itIt’s hard to estimate the “architecture effort”WHYIt is not always is like thatSometimes the system is legacy, but we still need to do our jobSometimes we need to maintain an existing systemSometimes is not just about Software Development
  • Provide value work on SOLUTIONS, not DOCUMENTSTry to optimize solutions for multiple stakeholders to reduce cost and effortFind COMMON solutions for common GOALSYou should support it in the future WHETER change is requiredMinimize complexity to keep the solution maintainable
  • GOLDEN RULESPEOPLEit’s all about people, VALUE PEOPLE -> MOTIVATION is a great asset to haveCOMMICATIONCOMMUNICATE with every stakeholder, ask questions, provide mocks and views and discuss it, INVOLVE, promote DISCUSSION and FEEDBACKS are ALWAYS welcomeLESS IS MOREEVERYTHING you PROVIDE to stakeholders has a COST, cost of MAINTENANCE, LESS you provide to communicate, less it will cost in the FUTUREEBRANCE CHANGESMake your ARCHITECTURE AGILE not FRAGILE, be capable to ADAPT to the MARKET CHANGESCHOOSE RIGHT SOLUTION CATCH the VISION of the stakeholders, try to PICTURE a GLOBAL vision in order to find the RIGHT ARCHITECTUREDELIVER QUALITY QUALITY your architecture in AGILE WAY, TEST your views, TEST your visions and ideas using other ACTORSAGILE DOCUMENTATIONPURPOSE, REASON, MODEL only what is REQUIRED, SIMPLE
  • PROBLEMS?context? We don’t knowUser WHO, WHAT?Buy and sell, HOW, WHEN?MISS VISION and CONTEXT, does not express enough
  • AGILE SOLUTIONS? Add details …The things become more complex, we can have now multiple USER STORIESSub tasks of a story and bugs and other BACKLOG ITEMSWHERE IS the architecture? How can my team understand how to operate on THESE stories?
  • Ok we have increase the number of post-it, but still don’t see an ARCHITECTURE hereIS REQUIRED?Of course because now we have to estimate these post-it without a VISION in our mindsWHAT’S MISSING?A Vision, a View of the System, a Flow of what we should achieveWe need something QUICK, UNDERSTANDABLE, MAINTAINABLE and it should fits a rich AUDIENCE
  • INTERPRETATIONThe issue is that a SENTENCE on a BOARD can be read by ANY STAKEHOLDERS andINTERPRED in a different WAYFEEDBACKS are too lateWithout VIEWS, VIEWPOINTS, MOCKS you can’t communicate properly with the STAKEHOLDERS until some piece of software is READYNO SPECIFICATIONS, OFTEN TOO GENERICThink about the BUILDING ARCHITECT, without a blueprint how the customer knows the RESULT?No SPECIFICATIONS, no CONVENTIONSNOT A TECHNICAL DOCArchitecture should still have ITS OWN REPOSITORY, its own DOCUMENTATION, the backlog is not an ARCHITECTURAL repositoryUser Story provides a link to a TECHNICAL DOCUMENT (Visio, ArchiMate, PDF)
  • Fibonacci STRING are not always working with different BRAINS4 values EXAMPLE …After few ROUNDS use always the same SCALEWHY? Otherwise statistics are not correctVOTE ALONE, WHY? Juniors get influenced by SENIORS and vice-versaDevelopers are NOT ALWAYS architects, they DON”T HAVE VISION so often they under estimateNO DISTRACTION, is a TECHNICAL MEETING, AGILE but still FORMAL and TECHNICAL
  • When I discover views and view pointsWhy I believe there are different views and styles for different stakeholders
  • THIS is what most STAKEHOLDERS of ACME.com explain to meCan we consider this a VIEW? Or better a MOCKUP?
  • THIS is what most DEVELOPERS of ACME.com needs in order to estimate
  • Four different types of estimationGUESSINGHere you are really guessing what could be the potential costLEARNINGAcquiring knowledge to provide a better estimationEXPERTISEProvide feedbacks and estimation based on experienceALGHORIT.Provide estimation based on specific rulesA – Main Vision to get approval on the projectB – Business development to support the proposed VISIONC – Description of the information system architectureD – Describe the phase where technology comes into playE – Grouping implementation projects (high estimation required)F – Description of the process to move from an original solution to the final solution proposed in the Vision phaseG – Governance, restrict, organize provide constraints and policiesH – Maintenance phase/process
  • In SCRUM estimation happens in multiple places/times
  • User story estimation with agile architectures

    1. 1. User Story estimation with Agile Architectures R. Garofalo - IFC @raffaeu
    2. 2. Agenda  Agile Architecture  User Story  Common Estimation Mistakes  Views and Viewpoints  Introduce Viewpoints in User Story estimation  Agile R.O.I.  The Estimation Game
    3. 3. Who I am  Raffaele Garofalo   IASA Member   Software Architect Kitesurf addict Contacts  Twitter: @Raffaeu  Blog: http://blog.raffaeu.com/  Mail: raffaeu@gmail.com
    4. 4. Introduction to Agile Architecture  What is agile architecture?  Agile Architecture key objectives  Agile Architecture principles
    5. 5. What is Agile Architecture?  What?   Why?   The main concept that stays behind Agile Architecture is:  “Bring agility to architecture”  “Bring architecture into the Agile world” Most Agile teams believe that an Architect is not required There are two major problems when we adopt Agile methodologies and bring them into our environment:  Agile assumes that a software needs to be developed  Agile assumes that we have a sort of control on how the system is and will be built How?  First of all we should be able to keep our agility while staying focus on the main picture, by bringing architecture into agile and vice-versa
    6. 6. Agile Architecture key objectives Also Agile Architecture has its own key objectives:  Deliver working solutions (a Diagram is not a working solution …)  Maximize Stakeholders’ values  Find a solution that meets the goals of all the Stakeholder  Enable the next effort  Being able to Manage changes and complexity
    7. 7. Agile Architecture principles  Value People  Communicate  Less is more  Embrace  Choose  Deliver  Model changes: plan and deliver the right solution for the Enterprise, not for your User Story quality and documentation in an Agile fashion
    8. 8. User Story  What is a User Story?  How can we add details to a User Story?  How you estimate a User Story?  Pitfalls of a User Story
    9. 9. What is a User Story?  User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:  “As a user, I can buy and sell stocks that are in my portfolio”  “As a portfolio manager user, I can act on portfolios for which I have permissions”  “As a user, I can reports that analyze my portfolios’ status”
    10. 10. As a USER, I can buy and sell STOCKS in my Portfolio
    11. 11. How can we add details to a User Story? Details can be added to user stories in two ways:   By splitting a user story into multiple, smaller user stories. By adding “conditions of satisfaction.” “When a relatively large story is split into multiple, smaller agile user stories, it is natural to assume that detail has been added. After all, more has been written” “The conditions of satisfaction is simply a high-level acceptance test that will be true after the agile user story is complete”
    12. 12. User Story estimation Pending As a USER, I can buy and sell STOCKS in my Portfolio As a USER, I can buy and sell STOCKS in my Portfolio As a USER, I can buy and sell STOCKS in my Portfolio … User auth. Port. Mgmt Docu ment. Stock Search Buy mech. Test QA 2 4 8 16
    13. 13. What are the pitfalls of a User Story?  Even the best written user story leave room for interpretation and interpretation is not design  Design is bring to the stakeholder when it’s ready and that’s the first time the Stakeholder can start to ask for changes  The format of the user story is too agnostic. “As a User …”: which, how, when?  Sometimes stories become very big and the whole architecture is described in the story details.  Unfortunately a User Story is not a technical document and it should not replace it
    14. 14. Common Estimation Mistakes  Don’t use Fibonacci, use the technique that fits your team (i.e. Power of 2 scale)  4 Values are more than enough to estimate a story  Define a size scale and stick on that  Vote independently  Always over estimate, never underestimate cause you will always forget about a requirement or impediment  No laptops/tablets and ask for participation
    15. 15. Views and Viewpoints  Definitions  Different Views for different audience
    16. 16. Definition  An Architecture View is   “Architecture views are representations of the overall architecture that are meaningful to one or more stakeholders in the system” An Architecture Viewpoint is  “A Viewpoint is an abstract model that can describe part of a View or a View in a specific context” So in essence each viewpoint is an abstract model of how all the stakeholders of a particular type see the overall system
    17. 17. Architecture Views and Viewpoints This is what most of the Stakeholders will understand
    18. 18. Architecture Views and Viewpoints This is what most of the Developers will understand
    19. 19. Merge Architecture into Agile
    20. 20. Some Numbers - ROI  Return of Investment  ” The term "return on investment" (ROI) is frequently used to describe the benefit derived  Formula:  ROI = (V1 – V0) _____________ I  V0 Initial Value  V1 Later Value  I Capital invested     Example:  Team cost (month): 50,000 $  Current rev.: 300,000 $  Estimated: 550,000 $  Project est. : 26  Team Velocity (be-week): 5 Result: (550,000 – 300,000) / ((26/5*2)/4.5 * 50,000) 26/5*2 = num of weeks / 4.5 = num of months 211% we spend 115K but gain 250K
    21. 21. The estimation game  Provide to an Agile Team few stories in the form of Comics  Provide a simple View of the Architecture  Ask the teams to use a common estimation scale  Give two hours to provide viewpoints with estimation on it
    22. 22. An effective estimation technique
    23. 23. TOGAF and estimation PHASE A LEARNING EXPERTISE ALGHORIT. PHASE C PHASE D PHASE E PHASE F PHASE G PHASE H Vision GUESSING PHASE B Business System Technology Opport. Migration Govern. Change Mgmt
    24. 24. SCRUM and estimation

    ×