4 – Agile Planning, Req’ts & Product Backlog - PowerPoint Presentation

4 – Agile Planning, Req’ts & Product Backlog Agile & Traditional Planning Practices… differ Traditional major planning (plan driven) before the start of the project SCRUM pulling prioritized sprint “work” from the Product Backlog… sprint planning is done by the team Rolling-Wave Planning (waterfall) Start with high level plan project plan that defines the vision, scope and objectives of the entire project Details and requirements may be “elaborated” over the life of the project An agile impact… “deferring planning decisions as long as possible results in better decisions…”

Typical plan-driven or Waterfall planning approach Cone of Uncertainty

Key things to remember… Always fit the methodology to the project based on characteristics of the project and other factors such as the training and capabilities of the team Whatever approach used should be based on the level of project uncertainty Plan driven versus adaptive (agile-Scrum) … management support and all the needed skill sets

4.2 Agile Planning Approach Project level Planning Release level Planning Iteration level Planning Project is defined to a sufficient level for Defining the scope & project objectives Typically consists of Project Vision User stories with story point estimates Current iteration defined for: Assigning development tasks Estimating tasks in hours Beginning developmentTypically consists of:Iterations BacklogDevelopment tasks, assignments, estimations Current release is defined to a sufficient level for Resolving any major questions or uncertainties Allocating user stories to releases and iterations Typically consists of : User stories ordered by priority or value Release backlog Design approach (logical database) Design UI Screens

Uncertainty When there is a question about how a “requirement” is interpreted and/or how best to approach the design and development work… Spikes A “sprint” (iteration) is used to do research, possibly prototyping a solution, and/or evaluating alternative approaches for resolving the uncertainty

Rolling Wave: Progressive elaboration “The key point is that you shouldn’t get too bogged down in planning requirements too far in advance… … the downside is too much speculation and th possibility of unnecessary rework Requirements should only be defined to support whatever decisions or action is required at that particular point in time” At the project level there may be a need to understand the overall scope of the project to evaluate resources, costs, and schedule req’ts …”

Rolling Wave: Progressive elaboration At the Release-Level , there may be a need for more accuracy in the estimated time and effort to complete the release… understanding req’ts in more detailAt the Sprint-Level … identifying what is needed prior to the start of a Sprint The team needs to have a reasonable estimate of the level of effort associated with “req’ts” in pulling work from the Product Backlog SCRUM requires the team and Product Owner build the Product Backlog … identifying the required set of Features and their User Stories and the estimates of the development work needed at the beginning

“Value-based functional decomposition” Plan-driven projects start with a “vision statement” that defines the business value that the “solution” is to provide. SCRUM … the business value is defined at the beginning in the development of the Product Backlog … identifying a priority list of Features and their associated user stories. The Product Backlog is prioritized by the Product Owner … the result being that the team is always working of the highest priority business value in each Sprint

Agile Requirements Practices The role of the Business Analyst in an Agile project… is that of the Product Owner“A Business Analyst is someone who analyzes an organization or business domain and documents its business or processes or systems, assessing the business model or its integration with technology. The Business Analyst helps in guiding businesses in improving processes, products, services and software through data analysis .” In most cases, the Product Owner is in fact the Business Analyst

The Business Analyst as Product Owner Representing stakeholder “needs” Creating the Product Backlog Identifies the “Features” and the user needs (user stories) associated with each feature… Including “epic” sized stories and features Provides user stories that are clear, concise and easy to understand

“Just barely good enough” The problem of “bloated requirements” Users asking for everything that they could possibly need… In addition, teams may go beyond the basic requirements and “gold plated” a solution…Excellence interpreted as “going far beyond user requirements… “Going beyond the user needs to develop a solution isn’t necessarily a good thing and can significantly increase the scope and complexity of the development effort.”

The five whys Differentiating wants from needs! Wants tend to be associated with a solution that a client envisions Needs tend to be associated with the problem“… typical for a user to tell you what they think they want for a solution before the problem the solution is intended to solve is clearly defined. … It is also a good practice to dig a little deeper into the problem to be solved to get to the root cause of the problem to be solved.”

The five whys … progressively ask “why” over and over again, to get to the root cause of the need or the problem… example Why is our client unhappy? Because we did not deliver our services when we said we would Why were we unable to meet the agreed-upon timeline or schedule for delivery? The job took much longer than we thought it would. Why did it take so much longer? Because we underestimated the complexity of the job. Why did we under estimate the complexity of the job? Because we made a quick estimate of the time needed to complete it, and did not list the individual stages needed to complete the project. Why didn’t we do this? Because we were running behind on the other projects. We clearly need to review our time estimates and specification procedures.

MoSCoW techniques Another approach to prioritizing requirements M ust have req’ts have to be included in the current delivery… if even one must req’t is not included, the project delivery would be considered a failureS hould have req’ts are critical to the success of the project, but are not necessary for delivery in the current sprint C ould have req’ts are less critical and often seen as nice to have W on’t have req’ts are either the least-critical, lowest-payback items, or not appropriate at that time

User Personas and Stories Used in agile for personalizing user requirements Req’ts typically are impersonal… not clear who the requirements are designed to satisfy. Organizing the project requirements around specific users and their needs puts more focus on really understanding the value that the project provides and who the recipient of that value is. Example Persona (page 65)

Fig. 4.3 Product backlog flow Inputs from Customers, Team Managers, ExecsProduct Owner List Requirements prioritized by Business value (highest value at to of list … Product Backlog

Fig. 4.4 Product Backlog Grooming flow Waiting for Development Fully groomed With acceptance criteria With story point estimates 2-3 sprints in Advance Waiting for Estimation High level Stories written without acceptance criteria No major issues to be resolved In Process Epics DefineMajor Story Titles DefinedTo be Defined: Functionality needsFurther definition

Waiting for Development Fully groomed With acceptance criteria With story point estimates Waiting for Estimation High level Stories written without acceptance criteria No major issues to be resolved In Process Epics Define Major Story Titles Defined To be Defined: Functionality needs Further definition 2-3 sprints in Advance Figure 4.4 Product Backlog Grooming Flow