Business Analysts Make Great Scrum Product Owners

There are three fundamental roles in Scrum: Product Owner, ScrumMaster, and Team. This article discusses the Product Owner in  how in many cases a Business Analyst is the best person to serve this role. Product Owner is the most demanding of the Scrum roles. The Product Owner creates a vision of what needs to be built and conveys that vision to the Team.  Effectively communicating this vision is key for beginning any agile software development project.  In Scrum, the Product Owner is the primary person responsible for ensuring that the solution delivers business value. The Product Owner leads the development effort by conveying his or her vision to the Team, creating requirements (user stories) in the backlog, and prioritizing user stories based on business value. The Product Owner must work closely with stakeholders and the Team to make sure their interests are included in the release. The Product Owner works closely with the Team to negotiate work assignments, resolve issues, and ensure that the agreed upon work is completed by the end of the iteration. The Product Owner must be available to the Team during the sprint to answer questions and deliver direction. This combination of authority and availability to the Development Team makes it difficult for the Scrum Product Owner not to micro-manage.  However, Scrum places significant value on self-organization and, as a result, the Product Owner must respect the Team’s ability to create its own plan of action. This means that a Product Owner is forbidden from assigning the Team more work in the middle of the sprint. Even if requirements change or some business dynamic arises...

Three Levels of Software Requirements

Enfocus Solutions Inc. has teamed up with Karl Wiegers to bring you a requirements management educational video series.  The videos delineate all aspects of requirements management, from simple concepts (“What Is a Requirement?”) to detailed explanations of industry standards (“Version Control”). Video Synopsis We can organize our thoughts about requirements with a three-level model.  The top level respresents business requirements – why are we taking on the project? The second level represents user requirements – whiat will the users be able to do with the system? The third level represents functional requirements – those that help users get their jobs done (what does the developer build?). Respectively, the three documents often associated with the levels are a Vision and Scope document, a User Case, and a Software Requirements Specification (SRS).  If you implement accurate functional requirements, your project should meet the user requirements and business requirements quite effectively. Watch the Karl Wiegers video...

Agile Delivers a Higher Success Rate

Agile projects are successful three times more often than Waterfall projects, according to the 2011 CHAOS Manifesto from the Standish Group. The report indicates “The Agile process is the universal remedy for software development project failure. Software applications developed using the Agile process have three times the success rate of the traditional waterfall method, and a much lower percentage of time and cost overruns.” The Standish Group defines project success as a project that delivers on time, on budget, and includes all planned features. Even though the Standish research shows the chances of success are much greater with Agile than using traditional Waterfall methodology, there remains a high chance (58%) that a project will be challenged, failed, or cancelled. Let’s examine some reasons why Agile projects may have problems. Poor Stakeholder Communication Poor communication between stakeholders and IT is a common downfall of any project; Agile projects are not exempt. Poor communications can result at several levels including product owner to stakeholder, product owner to team, and even team to team.   Unfortunately, stakeholders are frequently not be clear about what they expect from team members. Requirements and Specifications are Incomplete or Not Clear A major cause for failed Agile projects is that the requirements have not been thoroughly defined. Agile classes teach us to garner user stories; you are also taught to elaborate user stories with test cases and conversations.  Many teams seem to forget the test cases and conversations. I have seen this as a major problem on many projects. To avoid having a project with incomplete requirements, or an abstract scope, take the time to carefully define...

Principle #9 – Prioritize Requirements for Delivering Business Value

This is the ninth article in a series of blogs discussing individually each of the 12 Keys For Successful Enterprise Projects, published in my blog of Tuesday, June 26, 2012. Maintaining focus on project priorities can be extremely challenging within the culture of large enterprises. According to one industry study, 53% of project prioritization is driven by internal politics. In this climate, adapting more open and transparent project prioritization activities can be extremely difficult. There are powerful people who like the way things are and may have “pet projects” that are near and dear. But that doesn’t mean we shouldn’t try and prioritize by value – it just means bringing change may be harder than we think. One characteristic of excellent requirements is that they are explicitly prioritized. When customer expectations are high, timelines are short, and resources are limited, it is essential to make sure the product contains the most essential functions. Establishing each chunk of functionality’s relative importance lets you sequence construction to provide the greatest product value at the lowest cost. Customers and developers must collaborate on requirements prioritization. Developers do not always know which requirements are most important to the customers, and customers cannot judge the cost and technical difficulty associated with specific requirements. Thus, collaboration and effective communication are key. A project manager has to balance project scope against the constraints of schedule, budget, staff resources, and quality. One balancing strategy is to drop or defer low priority requirements to a later release when you accept new, higher priority requirements or other project conditions change. If customers don’t differentiate their requirements by importance and...

Principle #8 – Don’t Forget the User Experience

This is the eighth article in a series of blogs discussing individually each of the 12 Keys For Successful Enterprise Projects, published in my blog of Tuesday, June 26, 2012. User-centered design, often referred to as UCD, is a design philosophy in which extensive attention is focused on considering the needs, wants and limitations of end users at each stage of the design process.  User-centered design can be characterized as a multi-stage problem solving process that not only requires designers to analyze and foresee how users are likely to employ an interface, but to test the validity of their assumptions with regards to user behavior in real world tests with actual users. User participation enhances system quality through a more accurate and complete identification of user needs and expertise about the organization, while concurrently contributing to management of user expectations. Industry research clearly shows that the majority of failed projects can be attributed to incomplete or inaccurate requirements. The biggest cost benefit that UCD provides is defining more accurate requirements that directly address user needs. Design changes made late in the design process typically cost up to ten times more than if it the change were identified during requirements. Making changes to working systems after they are in place will cost about one hundred times more than changes identified in the requirement stage. Ideally, UCD activities should be integrated with other development activities. They should be planned and managed by the development team. Over time, UCD activities will become common practice, and existing members of the team will be able to carry them out. However, usability skills will most...