Business Analyst As Product Owner

  • 8,482 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
8,482
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
755
Comments
2
Likes
16

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. A FT D R Business Analyst as Scrum Product Owner Craig Brown BA World Symposium, 2009
  • 2. Introduction notes In this presentation I plan to elaborate on one of the several ways business analysts can step into the role of product owner. Who else is more suited than the masters of bridging gaps, delivering business value and getting things done? The first part of this talk runs through some generally accepted definitions of a business analyst’s role. I then briefly talk about the basics of scrum before diving into a more in-depth exploration of the Product Owner role (in enterprise contexts.) Lastly I talk about some of the areas I believe that BA’s may need to adjust their thinking when moving from a traditional BA role to the PO role. This conversation is far from over and your contribution to the discussion is most welcome. Craig Brown www.betterprojects.net
  • 3. Sponsored by IGL Ingena Group Limited Level 8, 30 Collins Street, Melbourne Vic 3000 www.ingena.com.au
  • 4. What is a business analyst?
  • 5. In 2007 and 08 I surveyed job descriptions for BAs to see what hiring organisations were looking for from business analysts. This is what I found.
  • 6. This role encompasses more than the ability to document processes and apply technological expertise. …wherever they sit, Business Analysts must be great communicators, tactful diplomats, problem solvers, thinkers and analysers - with the ability to understand and respond to user needs in rapidly changing business environments. We define the purpose of the role of the Business Analyst as being ultimately responsible for ensuring that organisations get the most from their limited IT and change management resource. Guy Beachamp http://www.businessanalystsolutions.com/what_is_a_business_analyst2.htm
  • 7. “...the most successful and valuable analysts are those who understand the "Business" rather than those who understand IT.” “A broad experience of business is required, the more varied, the better.” Derrick Brown and Jan Kusiak, IRM Training Pty Ltd
  • 8. The role of the BA differs from the role of the Project Manager in that the BA is responsible for defining and managing the scope of a business solution, while the PM is responsible for the work necessary to implement that solution. IIBA blurb http://www.theiiba.org/AM/Template.cfm?Section=What_s_a_BA_
  • 9. Business analysts often play a critical role in aligning the needs of business units with the capabilities delivered by information technology, and may serve as a translator between those two groups. It includes the definition of organizational goals, how those goals connect to specific objectives, determining the course of action that an organization has to undertake to achieve those goals and objectives, and defining how the various organizational units and stakeholders within and outside of that organization interact BABOK v2
  • 10. A Business Analyst is a professional who supports the evolution and implementation of business decisions via the application of specialist analytical tools, techniques and procedures. Brenda Treasure and Martin Vaughn Core Consulting for ABAA in Business Analysis Competency Framework http://www.abaa.org.au/cms/tiki-download_file.php?fileId=66
  • 11. As a BA, I find my client area is glad to have someone to deal with that “techo” stuff and therefore the challenge is to ensure a level of common understanding and “getting the business system right” first time. Maria Horrigan, SMS Technology www.barocks.com
  • 12. The professional business analyst… differs from traditional IS analysts in that it focuses almost exclusively on adding value to the business” Kathleen Haas, Management Concepts
  • 13. Business Analysts get the job done. It's that simple - they get the job done. When everyone else retreats, gives up, waffles or disassociates from the job the analyst gets the job done. HM Winning Trials and Tribulations of a Business Analyst, IT Toolbox http://it.toolbox.com/blogs/business-analyst/what-is-a-business-analyst-here-you-go-24325
  • 14. Business Technical
  • 15. What is a ‘Product Owner’
  • 16. Alexa Page rank search
  • 17. Laura Brandau Bridging-the-gap.com
  • 18. Laura Brandau Bridging-the-gap.com
  • 19. Scrum…
  • 20. …which is an agile thing
  • 21. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and over processes and tools interactions over comprehensive Working software documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more
  • 22. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and Scrum over processes and tools interactions over comprehensive Working software documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more
  • 23. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and over Scrum processes and tools interactions over comprehensive Working software documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more
  • 24. Principles behind the Agile Manifesto 1. Our highest priority is to satisfy the 1. Working software is the primary measure of customer through early and continuous progress. delivery of valuable software. 2. Agile processes promote sustainable 2. Welcome changing requirements, even late development. The sponsors, developers, and in development. Agile processes harness users should be able to maintain a constant change for the customer's competitive pace indefinitely. advantage. 3. Continuous attention to technical 3. Deliver working software frequently, from a excellence and good design enhances couple of weeks to a couple of months, with agility. a preference to the shorter timescale. 4. Simplicity--the art of maximizing the 4. Business people and developers must work amount of work not done--is essential. together daily throughout the project. 5. The best architectures, requirements, and 5. Build projects around motivated individuals. designs emerge from self-organizing Give them the environment and support teams. they need, and trust them to get the job 6. At regular intervals, the team reflects on done. how to become more effective, then tunes 6. The most efficient and effective method of and adjusts its behavior accordingly. conveying information to and within a development team is face-to-face conversation.
  • 25. Principles behind the Agile Manifesto • Our highest priority is to satisfy the • Working software is the primary measure of customer through early and continuous progress. delivery of valuable software. • Agile processes promote sustainable • Welcome changing requirements, even development. The sponsors, developers, and late in development. Agile processes users should be able to maintain a constant harness change for the customer's pace indefinitely. competitive advantage. • Continuous attention to technical • Deliver working software frequently, from a excellence and good design enhances couple of weeks to a couple of months, with agility. a preference to the shorter timescale. • Simplicity--the art of maximizing the • Business people and developers must work amount of work not done--is essential. together daily throughout the project. • The best architectures, requirements, and • Build projects around motivated individuals. designs emerge from self-organizing Give them the environment and support teams. they need, and trust them to get the job • At regular intervals, the team reflects on done. how to become more effective, then tunes • The most efficient and effective method of and adjusts its behavior accordingly. conveying information to and within a development team is face-to-face conversation.
  • 26. Scrum’s three aspects
  • 27. Sprint Process
  • 28. People (agile scrum) team Scrum master Product Owner 1,510,000 292,000 35,100
  • 29. People (agile scrum) team Scrum master Product Owner 1,510,000 292,000 35,101
  • 30. The product owner • Assure team is pursuing a common vision • Establish priorities to track business value • Act as ‘the customer’ for developer questions • Work with product management to plan releases • Plan, elaborate and accept user stories and iterations • Technical: understand and prioritize refactoring and infrastructure Dean Leffingwell, Scaling Software Agility
  • 31. User Stories (We’ll come back to that)
  • 32. The issue for BA’s assuming the Product Owner role is ‘authority’ Rochelle Glover, Fronde http://www.fronde.com/blog/?p=318
  • 33. C.R.A.C.K. Analysts (Barry Boehm, Richard Turner) Collaborative Representative Accountable Committed Knowledgeable
  • 34. Products (Deliverables)
  • 35. Pre-sprint work
  • 36. Post sprint implementation work
  • 37. Pre sprint Sprint Post sprint
  • 38. As a <user type> I want to <achieve a goal> So that I can <get some value>
  • 39. INVEST in good user stories
  • 40. Plus • Estimates* • Release plan • Acceptance criteria • “Acceptance” * Don’t produce them, but probably does report them
  • 41. Plus • Business Value • Balancing stakeholder needs • Implementation planning • Selling the solution
  • 42. Plus Constant interaction with the dev team
  • 43. Secrets to success • Early and often • Focus on value • Release focus • Avoid eating elephants • Test first approach to requirements • Done-Done (James Shore, The Art of Agile Development) • Communication, communication, communication (as usual)
  • 44. Questions? Craig Brown www.betterprojects.net
  • 45. View the notes page to see the credits and sources of the photos Craig Brown www.betterprojects.net This work is licenced under the Creative Commons Attribution 2.5 Australia License. To view a copy of this licence, visit http://creativecommons.org/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.