Welcome to the Home of Scrum! ™

Brief about me before you read this post so you can understand my perspective better. I am a software developer and Scrum Teacher. I have been in software development for 23+ years and have worked on various technologies and have played the role of a developer, analyst, project manager, delivery manager, scrum master, product owner, and coach. I teach and coach teams and individuals on agile project management using agile methods, agile product development using Scrum and LeSS, and Agile Software Development using Scrum, XP, and DevOps. Hoping it made clear that I don’t teach a role-based curriculum and focus on processes, practices, and methods. For me, the role is fluid, and if I know better techniques, procedures, and methods, then I can play any role that my team expects me to play. What is business analysis? It is a discipline and very popular in the software project management field. Traditionally, there is a role called a business analyst to perform all tasks related to business analysis. Requirement analysis is a phase to perform business analysis tasks within traditional project management techniques (waterfall is the most popular framework). In this phase, analysts determine problems, identify business needs, elicit requirements, and manage stakeholders to meet business and project objectives. During execution, they facilitate the implementation of the Product, service, or result of the project. Why a business analyst? Since analysis is a phase in traditional project management and usually longer (20–30% of project duration) and determines what takes to make a project successful, organizations ensure that they have the best possible people to perform analysis to decide the project continuity during phase gate review. Such needs promoted a culture to groom people in business analysis, and a disciple became a role over the period. I still remember my early days of software developer career, where we developers analyzed requirements and managed stakeholder’s expectations. Obviously, over the period, complexity increased as software started to control many things. The level of risk increases, so the demand for experienced professional business analyst grows many folds. Later, a professional body within this disciple came and started certifying people on their skills. We have thousands of people certified by IIBA, and the demand for certification is still growing. What is the Scrum Framework? Scrum Guide says — Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. It has THREE roles, and every role has clear accountability. The Product Owner is responsible for maximizing the Product’s value resulting from the Development Team’s work. The Product Owner does this by doing: Clearly expressing Product Backlog items; Ordering the items in the Product Backlog to best achieve goals and missions; Optimizing the value of the work the Development Team performs; Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and, Ensuring the Development Team understands items in the Product Backlog to the level needed. The Product Owner is one person, not a committee. The Product Owner is responsible for managing stakeholder’s expectations and engagements during product development. Can a Business Analyst (BA) take over the role of The Product Owner? It is a widespread practice where a BA plays The Product Owner’s role while developing a product using The Scrum Framework. Does The Product Owner need to learn disciple of business analysis? Looking at the above responsibilities of The Product Owner can easily understand how important it is for The Product Owner to have an in-depth understanding of business analysis. What if The Product Owner doesn’t have these skills? Can the outcome get impacted, or does it needed for The Product owner to learn business analysis? The answer depends on how well you interpret the below line. The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable. So here comes the second role, The Development Team and the following are characteristics of this role : They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment; Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person; Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and, Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. Can a Business Analyst (BA) be a part of The Development Team? There are two ways to think? We need business analysts in The Development Team, or we need business analysis discipline within The Development Team. Both options work, but I would prefer to have both. It is because of the fifth characteristic of The Development Team. Having a specialist ensures that discipline gets attention and continuously grow. But team knowing business analysis helps The Development Team not to be dependent on individuals. This approach becomes useful when multiple teams working on the same Product. One Product, one Product Owner, and one Product Backlog is the rule as per Scrum Framework, so when multiple Teams work, The Product Owner may struggle to deal with huge requirements and numerous stakeholders. The role of The Product Owner has to scale in such a situation. We have many ways to deal with depending on the context, but nothing beats having such discipline within the teams. LeSS framework talks about having area product owner, SAFe talks about having The Product Manager and group of Product Owners, and some companies have Proxy Product Owners. I can’t comment about LeSS or SAFe, but having a Proxy Product Owner will defeat the purpose of having a single Product Owner. I usually call them glorified business analyst. What can Scrum teams do to deal with such situations? Learn the business analysis discipline to support your product owner and be a cross-functional team. In such a case, teams perform better without being dependent on an individual’s skills where specialists take over the role of guardian for discipline and facilitate learning. IIBA has a couple of courses that suit such needs, such as Entry Certification in Business Analysis (ECBA) and Agile Analysis Certification (IIBA-AAC). I am not recommending to attend the IIBA program, but I didn’t find any other source highlighting this discipline as much as they highlight. Does Scrum teach all these or Scrum Trainers teach all these product owners or development team training? I have not experienced so far, but that doesn’t mean this is not a possibility. Do check with your Scrum trainer if you wish too. I wish you the best for your learning about business analysis in Agile. Connect to me if you need more information in this space.

{"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/vRx1Eqf_oNY.jpg?itok=ahy6myVa","video_url":"https://youtu.be/vRx1Eqf_oNY ","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} As part of the Scrum Tapas video series, Professional Scrum Trainer Roland Flemm explores the myth that a Daily Scrum is status meeting and reveals in 2 minutes how to make your Daily Scrum event more valuable.

What should the Development Team do when the Product Owner asks them to do work that was not planned during Sprint Planning?

El compromiso del equipo de desarrollo durante el Sprint es lograr el Sprint Goal y con ello el impacto en los clientes y en el negocio. El éxito del Sprint está asociado al logro de este objetivo y a los cambios en el comportamiento de los clientes que se puede provocar con el uso del producto.