Different Approaches in Agile and Traditional Planning Practices

4 Agile Planning, Reqts & 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 is defined to a sufficient level for Defining the scope & project objectives Typically consists of Project Vision User stories with story point estimates Project level Planning Release level Planning Iteration level Planning 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 Current iteration defined for: Assigning development tasks Estimating tasks in hours Beginning development Typically consists of: Iterations Backlog Development tasks, assignments, estimations

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 detail At 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-drivenprojects 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 Must 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 failure Shouldhave req ts are critical to the success of the project, but are not necessary for delivery in the current sprint Could have req ts are less critical and often seen as nice to have Won 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, Execs Product 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 Define Major Story Titles Defined To be Defined: Functionality needs Further definition

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 Figure 4.4 Product Backlog Grooming Flow In Process Epics Define Major Story Titles Defined To be Defined: Functionality needs Further definition