Agile Rolling Wave Planning 6y411v

rolling wave planning: ◾ You typically start with a high-level plan that is sufficient for defining at le ast the vision, scope, and objectives of the project to whatever level of detail is needed at that point to whatever level of planning and estimation is required for the project. ◾ The details of the plan and the requirements are further elaborated as the proje ct progresses. Planning strategies waterfall vs agile ◾ You should always fit the methodology to the project based on the characteristic s of the project and other factors such as the training and capabilities of the project team ◾ One of the biggest factors that influences the selection of an approach is the l evel of uncertainty in the project. ◾ It is not a black-and-white decision to be totally plan-driven or totally adapti ve. There are plenty of alternatives between those two extremes. a technique called a spike is often used in an agile project to resolve uncertai nty. A spike is a special kind of iteration that is used to do research, possibly pro totype a solution, and/or evaluate alternative approaches for resolving uncertainty associated with develo ping a solution. progressive elaboration: Requirements should only be defined to the extent neede d to whatever decisions or action is required at that particular point in time. project level> release level -> sprint level Value-based functional decomposition start with a vision statement that clearly defines the business value that the s olution will provide, A vision statement should be short and succinct. example of a format: ◾ For (target customer) ◾ Who (statement of the need or opportunity) ◾ The (product name) is a (product category) ◾ That (key benefit, compelling reason to buy) ◾ Unlike (primary competitive alternative) ◾ Our product (statement of primary differentiation) Once a high-level vision statement has been defined use functional decomposition to break down that vision statement into the functionality that will be needed to achieve that overall vision. Functional decomposition becomes particularly im portant on large projects where there could be hundreds of stories. It prov ides a hierarchical approach for organizing and prioritizing requirements. business analyst primary functions in agile: -Analyze a broadly defined area and use functional decomposition to define highlevel epics and stories to create a well-organized, value-driven framework to provide the requir ed business value in the product backlog. -Write individual stories that are very clear and concise and are easy to unders tand and implement by the project team. -Identify related stories and epics, grouping them into a logical structure

as necessary and documenting the interrelationship and associated business process flows as neces sary. -Integrate the needs of various stakeholders to produce an overall solution. a very important principle in agile is simplicity and limiting a solution to wha t is “just barely good enough” to solve the problem. There is an optimum point, and beyond that point, adding additional features has diminishing value. It requires close collaboration with the s to find where that optimum point is. A good technique is to start with the simplest and most basic solution possi ble and then add to it incrementally and iteratively only to the extent that it adds value to the . Another very good technique in developing requirements for agile projects is to differentiate wants from needs. ◾ Wants tend to be associated with a solution that a client envisions. ◾ Needs tend to be associated with the problem. The five whys method is a good approach for digging into a customer need to get to the root of the problem. The idea is that by progressively asking “why” over-andover again, you eventually get to the root cause of the problem. Another very good technique for prioritizing requirements is called MoSCoW, must have, should have, could have, won't have Organizing the project requirements around specific s and their needs puts m ore focus on really understanding the value that the project provides and who th e recipient of that value is. To facilitate that process, it is useful to identi fy personas as specifically as possible so that the project team can target their development efforts at the needs of those specific s. A persona could be a specific category of or it could even be a specific , but in either case, it is useful to model that ’s personality and specific interests as a hypothetical persona. A persona helps the team visualize that us er and focus its efforts around the ’s needs. stories stories are a succinct way of defining requirements in agile. Telling stories is a way of simplifying the definition of the requirements in a language that can be easily understood b y both developers and s. It breaks the requirements into small chunks of functionality that ca n be built incrementally. stories follow the general format shown below: As a I want so that Independent: Stories should be as “independent” as possible so that they can be work ed on in any order. That will simplify the flow of stories through development and avoid bott lenecks that can be caused by having too many dependencies among stories. Negotiable: Stories should be “negotiable”—a story is a placeholder for conversation, and some dialog is expected to take place to explore trade-offs associated with developing the s tory as efficiently and as effectively as possible.

Valuable: Stories should be “valuable”—the value that a story is intended to produce s hould be clearly-defined so that the product owner can make an objective evaluation of th e level of effort required versus the value to be gained from the story. Estimable—“Estimable” is the next important characteristic. A story needs to be suffic iently defined so that the team can develop a high-level estimate of the effort required for th e story in story points. Small—Stories should be relatively “small” so that functionality can be developed and tested as incrementally as possible. Breaking the work into small chunks allows it to flow much more smo othly and allows the work to be distributed more evenly among the team while large efforts can easily lead to bottlenecks and inefficiencies in distributing work among the team. Testable: Finally, stories should be “testable” to determine if they have successful ly fulfilled the value proposition that they are intended to fulfill. It’s a good practice with agi le stories to write acceptance test criteria, along with the stories to define the tests that they n eed to fulfill. The test criteria essentially take the place of more detailed specifications for what the story must do. Epics An epic is basically a very large story. An epic serves the purpose of asso ciating related individual stories with a higher-level purpose that they are collectively intended to fulfill, but an epic is normally too large for the project team to work on directly without breaking it down into individual stories. It’s a useful technique on large, complex projects for organizing st ories into some kind of structure so that the interrelationship of stories is well-understood. T he following shows an example of a large epic and how it can be broken down into smaller stories. The product backlog consists of stories, and it is dynamic. The storie s are continuously groomed and prioritized over the course of a project. It is essentially a queue of work to be done. The principles of rolling-wave planning are used in product backlog grooming and items start out at the bottom of the backlog as being very roughly defined and the stories are progressively “groomed” as they mo ve closer