7

Agile Analysis and Design

KNOWLEDGE AND SKILLS LEVEL

Introduction

Agile analysis and design start with creating the roadmap for the product, which is often a high-level view of how the sponsor or the customer wants the features to be released. Based on this, the requirements are elaborated further to come to a point when all the doubts are clarified and it is ready for implementation. Successful gathering of requirements is a key to the success of any project. Unlike the traditional model where the requirements are gathered at the beginning of the project and tried to be kept frozen throughout the project life cycle, the Agile framework allows the flexibility to progressively elaborate the requirements throughout the life cycle. That is the reason why in Agile projects the different levels of requirement details are captured in the number of artifacts like Product roadmap, Product backlog, Release backlog and Sprint backlog as will be discussed further in this chapter. The different techniques used for gathering the requirements are very important to know and that will be the starting point of the requirement analysis discussion.

Collecting and Validating Requirements of Agile Projects

Based on the project complexity, availability of the stakeholders, knowledge level of the end-users and the client, and the proficiency of the requirement analyst, the most suitable requirement gathering technique needs to be selected. The different requirement collection and validation techniques explained below are preferred for Agile methodology because all of these encourage and facilitate the direct interaction between the stakeholders of the project.

Interviews

Begin the interview with stakeholders who are believed to have a complete understanding of the requirements. Face-to-face contact with users through individual interviewing is the primary source of requirements and an important way to gather and validate their requirements. Interview techniques are used when the requirements are detailed and differing opinions are likely sought. In the distributed Agile, the interview is the main technique used to gather requirements. Even if the team and the customer are collocated, we can use the interview technique to clarify doubts. During the execution of the project at any point of time interview may happen with the product owner to clarify the doubts.

Causes/Solutions

Write the problem that has been identified on the flip chart and then divide the paper into two halves, one half headed Causes and the other Solutions. Get team members to contribute to both columns. Each contribution should be discussed and agreed before being added to either column.

Future Visioning

Ask participants to imagine they are at some point in the future (e.g., 2010). They should imagine that all their problems are resolved, dreams have been achieved, and goals have been achieved. Now step back and describe how we did it.

It is important to spend some time on placing the participants in the future. Use the past tense when asking how we did it. This technique can be useful when problems seem insurmountable or when the group has low morale.

Mind Map

Facilitate discussion with a group and record the output in a large mind map drawn for all participants to see—on a flip chart or large sheet of paper pinned to the wall. Mind maps are an expression of radiant thinking, a natural function of the human brain, and they allow creative ideas to bloom and flow. They provide a basic ordering of information and easily allow later additions as the session progresses.

Greenfield Site

Ask participants to imagine the problem and then imagine there were no history, rules, regulations, culture, or climate. If none of these things existed because we were just starting up what might we do, how might we approach the solution.

Celebrity Views

Split the group into smaller sub-groups. Each sub-group decides upon a celebrity (dead or alive, fact, or fiction). Each sub-group then explores the characteristics of their celebrity and decides how the celebrity would view the problem at hand. Each group then presents their solutions to the plenary. This method can be used in a variety of different ways, i.e., participants can imagine what someone they admire might do, etc. It is a useful technique for viewing a problem and solutions from a fresh angle.

Big Picture

Another way to take a fresh approach to solution finding is to facilitate discussion in the group and record the output as a big picture for all participants to see. This provides a graphic representation of the problem and enables participants to visualize solutions, stimulating further ideas. This will appeal to participants for whom the visual channel is important and generate fresh ideas. It is also useful for building ownership.

Focus Groups

Focus groups are basically interviews, but it is more focused on the number of participants is restricted to 6 to 10 in one group at one point in time. We can get a lot of information during a focus group session.

Types of Focus Groups

  1. Two-way focus group—one focus group watches another focus group and discusses the observed interactions and conclusions.
  2. Dual moderator focus group Model 1—one moderator ensures the session progresses smoothly, while another ensures that all the topics are covered. This will ensure smooth progress of the session along with the entire topics of discussion.
  3. Dual moderator focus group Model 2—two moderators deliberately take opposite sides on the issue under discussion. This is more helpful to find the pros and cons of both the opposite views and will be helpful to take a final decision.
  4. Respondent moderator focus group—Respondents are asked to act as the moderator temporarily and because of this, they take ownership of the session and hence we can collect the requirements successfully and the outcome will be helpful.
  5. Client participant focus groups—Client representatives participate in the discussion and will ensure ownership from the client on the decision taken. Most of the projects fail at the last stage of the project lifecycle particularly in user acceptance testing phase. The reason being the client may not take the ownership of the initial requirements as the end-users have more ownership in it because they took the decision regarding the system in the beginning. But client participant focus group helps to overcome these kinds of problems.
  6. Mini focus groups—Groups are restricted to four or five members rather than 8 to 12 and are helpful to avoid confusion; it will be easy for us to manage and gather the requirements quickly.
  7. Teleconference focus groups—telephone network is used.
  8. Online focus groups—computers connected via the internet are used.

Facilitated Workshops

Workshops can be used for rapidly pulling together a good set of requirements. Workshops are very quick and best way to gather requirements than all other techniques.

A workshop is expensive because it involves many people, but it saves a large amount of time for us.

Here we use the brainstorming technique to gather requirements from the people. Requirements are discussed at the high level. Workshops are being conducted particularly when the requirements are focused on one area of business in which the participants have knowledge, and consensus is being sought.

Learning Cycle

Learning curve: This term refers to the decrease in time taken to perform a task because of the increase inefficiency in performing the task that results solely out of repeatedly performing the task. Therefore, with the passage of time, although total costs typically increase, the cost per unit drops. This pattern of cost reduction is given by

 

Yx = (Kx)log2 b

 

where K is the number of direct work hours required to produce the first unit, Yx is the number of direct work hours to produce the xth unit, x is the number of units produced and b is the learning percentage.

Participatory Decision Model

Agile projects encourage decision-making with the full participation of the relevant groups. In these groups, members meet face-to-face and rely on both the verbal and nonverbal interactions and brainstorming to communicate with each other.

Brainstorming is meant mainly to overcome pressures for conformity in the interacting group that retard the development of creative alternatives.

It does this by utilizing an idea-generation process that specifically encourages any and all alternatives, while withholding any criticism of those alternatives.

In a typical brainstorming session, about six people sit around a table and the group leader states the problem in a clear and understandable manner so that it is understood by all the participants involved. Members then can suggest as many alternatives as they can in a given length of time. No criticism is allowed strictly, and all the alternatives are recorded for later discussion and analysis. Brainstorming, however, is merely a process to generate ideas.

The Nominal Group Technique usually restricts discussion or interpersonal immunization during the decision-making process, hence, the term nominal. The members are all physically present but all members operate independently. A problem is presented and members do the following steps.

  1. Members meet as a group and each member independently writes down his or her ideas on the problem before the discussion.
  2. Each member presents at least one idea to the group. No discussion takes place until all ideas have been recorded by all the people.
  3. The group now discusses the ideas in detail for clarity and evaluates each one of them with its pros and cons.
  4. Each group member independently rank orders the ideas. The ideas with the highest aggregate ranking go for the final decision.

The main advantage of the nominal group technique is that it permits the group to meet formally but does not restrict independent thinking.

The interacting group is good for building group cohesiveness, brainstorming keeps social pressures to a minimum, the nominal group technique is very cheap for generating a large number of ideas, and electronic meetings process ideas fast.

Styles of Group Decision-making

The figure below represents different styles of group decision making.

 

img

Command Style

Here the leader makes a decision for a group with little or no input from the members of that group. The group members may provide specific information on request, but are not asked to contribute toward finding the final solution. This is like an autocratic decision. The advantage with the ‘command’ style is that the decision is made quickly. The disadvantage of the ‘command’ style is that although group members may have been consulted, some or all of them may still disagree with the decision that has been made, and therefore may have little or no commitment to that decision.

We can use the ‘command’ style of group decision making when any of the followings applies:

  1. the group perceives you to be the ‘expert’,
  2. the group asks you to decide,
  3. there is not enough time to use a consultative or consensus style of decision making (e.g., in a ‘crisis’ situation).

Consultative Style

In this case, the leader looks for input and advice from the group before making a final decision. The decision will meet the needs of the group. Group members have been consulted but some or all of them may still disagree with the decision that has been made.

We can use the ‘consultative’ style of decision making when any of the following applies.

  1. The group does not have the information, education, skills or experience to make a high quality decision.
  2. The group does not share the same goals or objectives that you hope to achieve by solving the problem.

Consensus Style

The ‘consensus’ style of group decision making refers to a situation where the leader seeks input and advice from the group, and works through the decision-making process with the group, until every member of the group can ‘live with’ the final decision that is made. We can call this a democratic solution as everybody takes part in the final decision. It leads to a high degree of ‘buy-in’ and commitment to the decision by all members and they are actively involved in the decision-making process and all of their interests are addressed, but it takes longer time as gathering a group of people is very difficult.

We can use the ‘consensus’ style of decision making when any of the following applies

  1. The group shares the same goals or objectives.
  2. All supports the decision reached irrespective of their own opinion.
  3. Plenty of time available to take a decision.

There are multiple methods of reaching a group decision.

Unanimity Everyone agrees on a single course of action
Majority Support from more than 50%
Plurality The largest block in a group decides even if a majority is not achieved
Dictatorship One individual makes decision for the group

Thumb voting is a quick way to check for consensus. In this method, holding the thumb up means I agree, holding the thumb down means I disagree, and holding the thumb sideways indicate that the member will go along with the decision of the group.

Exercise 7.1 List Down Five Consequences of Not Collecting Proper Requirement

_________________________________

_________________________________

_________________________________

_________________________________

_________________________________

Product Vision

Before any project starts, be it an Agile project or a traditional one, all stakeholders should be on the same page with regards to the final goal. Its all the more important since in Agile projects, due to the small iteration cycles the team often concentrate on churning out more work in immediate iterations and as a result, lose sight of the overall project objective. The overarching goal of the project which clearly defines its success criterion is called the Product Vision. All the stakeholders – Product Owner, Scrum Master, Team, Management, Customers and other stakeholders should share this same goal. According to Ken Schwaber - “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.” (Schwaber 2004, p. 68)

The product owner should lead the vision creation activity along with the team, because at the end the Product owner is the person who is responsible for driving the success of the project and the return on investment. The basis of the product vision is the customer needs and product attributes that will address those needs. It is important that the product vision is stable for a project as otherwise the team will get demotivated and confused leading to project failure if the vision itself is changed too often.

Product RoadMap

A product roadmap is a plan where the features are planned for release on a timescale. By looking at the product roadmap the business users and marketing team of the customer will come to know when a particular feature will be made available for use.

This plan talks about the following:

  1. Adding value to the customer in each release
  2. When releases are needed
  3. Features/Details Common about Each Release
  4. Date/content/objectives of each release
  5. Overall product features (Product Backlog, Business Story)
  6. Technical backlog (technical story /non-functional requirements)

The product roadmap is drawn by the product owner. The product roadmap is actually a prioritized work, a list of all product features and non-functional items along with the plan for release. Product backlog and product roadmap are maintained by the product owner. Product backlog items can be added by anyone at any time provided the item has a business value attached to it.

img

Figure 7.1 Product roadmap

We also need to continuously identify and prioritize

  1. Environmental factors
  2. Operational factors and
  3. Infrastructure factors

in order to improve the quality and value of the deliverables.

Backlog

Product Backlog

Project Backlog: My login

Requirement Number Requirement Description Requirement Estimation
01 User should be able to login to the system 03
02 User should be able to retrieve their personal information 03
03 User should be able to send e-mail to other users 02
04 User should be able to update their personal information 04
05 User should be able to retrieve the password in case the user forgets the password 01
06 User can enter their bank details after successful login 08
07 User can retrieve and update their bank details in a secured fashion 06
…..
Total project estimate in story points 95

The product backlog is cumulative of all the stories which are yet to be implemented. The features which were incorporated in the previous iterative cycle (sprint) are no longer part of the current product backlog or are marked as ‘Done’. For marking a user story as done it is important that it passes all the acceptance tests associated with it. Otherwise, the status of the user story remains ‘Incomplete’. The overall product backlog gets adjusted based on the execution of the recent iterative cycle (sprint) which is reviewed during the checkpoint. The following is a list of the questions to be answered during the client review or team retrospective phase:

  1. What was planned (scope) in the cycle?
  2. What was done (scope) in the cycle?
  3. Is the team working as expected?
  4. What went wrong in the concluded cycle?
  5. What went well in the concluded cycle?

The answers to the above questions are key inputs to the planning of the next cycle and the functionalities to be added into the cycle. So we have the original work (scope) of the next iterative cycle and thus we have the potential revised work (scope) to consider as a result of the checkpoint. In Agile, the change management process is embedded in the client checkpoint. Changes are accommodated in Agile only in between iterative cycles (sprints). No changes to scope are incorporated within an ongoing iterative cycle (sprint).

The user stories in the product backlog are at high level and are elaborated as the project progresses. The estimation of the items is done based on the relative complexity model mostly with story points. The total of the story points gives a basic idea of the size of the project at a very early stage though this estimation is at a high level. Remember that the prioritization of the user story should take into account three parameters—the business value associated with the story, the cost of developing the story, and the risk involved. So, the high value low risk items are implemented first while the low value high risk items are prioritized for the end.

Product Backlog Refinement/Grooming

Though Product backlog Grooming or Refinement session is added as a formal Agile ceremony, this is a very important step to keep the backlog up-to-date and correctly prioritized. The reasons why product backlog update may be required are as follows:

  1. Change in market condition, which added/deleted some features (stories)
  2. Technical constraints or findings
  3. Findings from the previous sprints
  4. Product architecture change
  5. Introduction to new competitor product
  6. Discussion with the customer reveals additional requirements
  7. Customer altered the internal network that will interfere with the functionality of the end product

The frequency of the backlog refinement session depends on how long the priorities can remain constant or how frequently new business requirements emerge or change existing ones. Some Agile teams fix a 30-min time slot each week when the team and the end users discuss the new or changed requirements, prioritize them to add in the product backlog, and quickly estimate those in story points. Even if weekly refinement is not required, the team should do it at least once 2-3 days prior to the iteration end date. Once the product backlog is updated the estimation is to be updated so that the team gets visibility of the pending works (Refer Figure 7.2).

The release backlog is also refined at the end of every Sprint and at the end of releases. Refinement includes addition, deletion, modification of requirements, and also prioritization of requirements based on the previous works completed. We also do the refinement of estimations based on previous actual data like velocity.

The feedback from the development team and the end users gets incorporated into the product and release backlog, which provides visibility of the remaining work in the project and any risk that has come out as a part of the new technical or functional requirements. This is termed as the Product Feedback Loop.

Release Backlog

A release backlog is a subset of the product backlog that is planned to be implemented and released in the coming release. A release backlog would presumably contain the same type of items as on a product backlog—preferably user stories. So, during the release planning meeting, a product owner with help from the team and other stakeholders would select the high priority stories and move those items to the release backlog.

The main purpose of the release backlog is to provide the visibility to all stakeholders including the team members of what need to be worked on in next 1–6 months which is the normal release cycle.

Sprint Backlog

The sprint backlog is the list of work the team will work on during the current iteration/sprint. At this stage, the features are broken down into tasks, which, as a best practice, should normally be between 4 and 16 hours of work. As the level of details is very granular, the whole team understands exactly what to do, and potentially, anyone can pick a task from the list. In Agile projects, the tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed in accordance with the set priority and the team member skills. This helps to create the self-organizing team and ensures developer buy-in.

In the following example, a list of five requirements is selected from the product backlog to implement in the next sprint.

Sprint N

Requirement Number Requirement Description Requirement Estimation (story point)
01 User should be able to login to the system 03
02 User should be able to retrieve their personal information 03
03 User should be able to send e-mail to other users 02
04 User should be able to update their personal information 04
05 User should be able to retrieve the password in case the user forgets the password 01
Total project estimate in story points 13

Each of these stories will be broken down into tasks as shown below and a more accurate estimation (in hours) is arrived at for the allocation of the tasks.

Below is a sample of the typical tracking sheet used by the Agile teams to track the work pending at the end of each day. So, the Day 1 figures under the column ‘Work Left’ represents the total estimated effort for the particular task which goes down as the work is done on them.

 

img

The above is just an example of how user stories are broken down into tasks and is not a representative of the real world scenario. Based on the complexity there might be more or fewer tasks. Ensure the following points regarding the sprint backlog:

  1. The team has taken each requirement in the sprint backlog, broken it down into tasks and estimated the tasks in hours.
  2. Till the team starts working on some of the tasks, all the tasks are pending and the work remaining for each of the tasks is the same as the team has estimated.
  3. In order to really mark all the requirements as done at the end of the sprint, it is important that the team should think of all the tasks it can for each requirement during this stage, note it down and estimate it as best as it can and then quickly move to the sprint.
  4. This is not used for getting a precise estimate of hours but an indication of effort/tentative plan will be enough.
  5. The team may find out additional tasks for requirements in the middle of the sprint as they move along developing the requirement. Then the spring backlog is updated with the new task added. For instance, the team might identify that more integration testing is required for requirement 01 after all requirements are done and adds this task to the backlog. The idea is to make sure to capture everything that needs to be done for the sprint in the sprint backlog.
  6. The team members generally volunteer for each of the tasks with the Scrum master facilitating in the case of indecision or confusion.
  7. Team members can swap the tasks or help each other during the sprint. But the new allocations should be updated in the sprint backlog.
  8. As you can see, the sprint backlog would be updated each day and at the end of each day, you will know exactly where you are. This gives you an insight whether you are headed for completing the requirements or not planned for the current sprint.
  9. If there are special requirements like additional documentation or additional regression testing, those should be identified and estimated as different tasks.
  10. During the iteration planning meeting if it is found that a story cannot be fitted inside an iteration then the team should explore the option to split the story into smaller stories.

During the iteration planning meeting if it is found that a story cannot be fitted inside an iteration then the team should explore the option to split the story into smaller stories.

Story Maps

User story mapping is a technique to organize and prioritize user stories. The main aim of user story mapping is to understand the end-to-end user requirements and stitch them in a logical thread so that users get maximum return on the business value. The benefits of a user story map are as follows:

  1. Provide visibility to the workflow or value chain
  2. Bring out the relationships of larger stories to their child stories
  3. Help the team understand the completeness of the backlog
  4. Provide a basis for prioritization
  5. Plan releases as complete and valuable slices of functionality for maximizing the business value

Below are the steps followed for creating a user story map:

  1. Start with the major user activities [stories] to elaborate the end-to-end use of the system
    • Arrange activities left to right in the order to show ‘What do users do with this system?’

     

    img
  2. Detail the tasks involved against the user stories and arrange them side by side from left to right in the order for the user to perform the tasks.

     

    img
  3. The user may be performing multiple parallel tasks to achieve a bigger task. Arrange these smaller tasks one below the other. For example, the user may be entering the customer details, verifying the ID proof and scanning the original documents to complete the customer registration process and all these tasks may go on simultaneously.

     

    img

    While discussing the workflow and the task level details with the users you may get information regarding granular level subtasks that the user is performing for a particular task. This information will be useful while developing the software related to those tasks. So record them in the story card, but do not use in the story map for the sake of simplicity.

     

    img
  4. So, the user story map created is a typical workflow of the system and also the decomposition of the requirement at the task level.

     

    img

    Arrange the tasks in the order of necessity, keeping the highest priority ones at the top.

  5. This map now makes it easy for you to choose the user stories for subsequent releases. The figure below shows how simple it is now to divide the features into releases and more so because each set of user stories chosen for the releases make an end-to-end system which will be useful for the customer.

     

    img

    This leads us to the next logical discussion of how the requirement should be captured in an agile project and validating the same with the customer.

Agile Modeling

After collecting and validating the requirements, it is crucial that the team has the required clarity to start the design and at the same time, the customer and the end-users are in agreement of what is getting built. In traditional models like the waterfall technique the customer and the user community get to see the end-product only toward the end of the project which causes a lot of friction at that stage due to expectation mismatch. But according to the Agile principle, showing the product to the end-users as early as possible is the key to success. Agile modeling techniques thus serve a dual purpose—clarify the doubt of the development team to start on the design with confidence and provide the end-users an opportunity to see the sample of the end-result at the early stage. There exist several modeling techniques as discussed below and based on the project scenario one or combination of more than one techniques can be chosen.

Prototype

A model or prototype is an original type, form or instance of something serving as a typical example, basis or standard for other things of the same category. The word ‘prototype’ derives from the Greek word ‘prototypon’. Prototypes and models are the best ways of presenting ideas to users. They give users a glimpse of what they might get. More requirements are likely to emerge when users see what they will get and through your suggestion. This technique aims to get users to express requirements. The prototype is used to get feedback from the user. Business logic may not be coded in prototyping. Experimental systems are developed using prototyping. It is actually an initial version of the system. It is used in the user interface, design and testing.

Types of Prototype

There is no general agreement on what constitutes a ‘prototype’. Figure 7.3 represents different types of prototypes.

  1. Proof-of-principle prototype (breadboard): Used to test some aspect of the intended design without attempting to exactly simulate the visual appearance. Few working codes are part of it just for understanding the purpose.
  2. Form study prototype: This type of prototype will allow designers to explore the basic size, look and feel of a product without simulating the functionalities.
  3. Visual prototype: It simulates the appearance, colour, fonts and surface textures of the intended product but no representation of the final function(s) of the final product.
  4. Functional prototype: It is also called a working prototype. It simulates the final design, aesthetics, materials and functionality of the intended work.

Advantages of Prototyping

  1. Early visibility to users
  2. Encourages active participation among users
  3. Cost effective (development costs reduced)
  4. Increases system development speed
  5. Helps to reduce the potential risks of delivery
  6. Improve system usability
  7. Closer match to user needs
  8. Design quality improves (try out choices) improve maintainability.

 

img

Sometimes the incremental system development is preferred over the prototype building as the former leads to a usable product. But prototypes are preferred when the complete specification needs to be validated within a short span of time. The basic requirement is the input for both prototypes and incremental system. But the prototype is used to develop the complete specification of the system and incremental system develops the usable product.

Wireframes

The visual forms of the prototypes are referred to as wireframes as well. Normally wireframes are used to substantiate the architecture design and the interfacing requirements along with the visual representation so that the team faces fewer challenges while actually implementing the software.

Personas

Persona creation is a technique of researching and developing a model for the most important customer when you try to see things from the customer’s point of view and try to understand their requirement better. Persona is the imaginary representation of the user role which helps in understanding the users of the product better. To this add the personal details to this imaginary character such as:

  • Likes and Dislikes
  • Profession
  • Color of the car

Add as much detail as possible, for example instead of saying he is a professor, mention that he is a professor of Biology at The University of California. Also, you may add a portrait of the persona also if it helps in making the team understand the character.

Persona design helps you to:

  1. Identify which group of customers you need to value most.
  2. Enhancing your understanding of your customers profoundly and in detail.
  3. Discover customer needs in details and unearthing requirements which your customers themselves have not recognized.
Business Case Development

The preparation of business case helps in gaining the confidence of the stakeholder and easy project approval. While developing the business case for Agile development, you might have to take two types of approaches. First, there may be doubt in the stakeholder’s minds on how while executing a project in Agile will provide some benefit. And second how the project will be adopting the Agile methodology to maximize the ROI. Both these things need to be handled differently. For the first part, the below findings will help:

Some statistics demonstrating the business case for implementing Agile processes are as follows:

  1. Agile projects are 16% more productive than traditionally-managed projects.
  2. Agile projects have a 37% faster time to market at a statistically significant level of confidence.
  3. Fifteen months after adopting Scrum, an Agile methodology, 86% of Salesforce.com employees reported much higher job satisfaction.
  4. During their first year of being Agile, Salesforce.com reported that they delivered six times more value.
  5. According to University of Calgary research, there is two-thirds less overtime when Agile processes are implemented.
  6. After implementing Agile methods, the vast majority of respondents in a VersionOne study reported that defects had gone down by 10% or more.

However, experts warn that this may not be the case for everyone. Agile is a significant change from traditional project management approaches and thus organizations might face some resistance to the implementation of Agile methodologies. According to Rich Mironov, the chief marketing officer at Agile consulting firm Enthiosys:

‘I haven’t seen [anybody] goes through a transformation where everybody came out the other side happy. You’ll lose some folks because it’s not a style fit or they weren’t very good and you may not fit with agile. Expect some fallout or some people who need to move to the part of the organization that’s not going this way’.

The second part is to make sure that the stakeholders are shown the benefit of executing the current project in the Agile methodology rather than in the traditional model. A business case report includes the market research data and the reasons for initiating the project. Prepare the business case based on:

  1. Technical feasibility: Is the software under development fit for Agile development model?
  2. Team readiness: Is the client and the project team ready for the deeper involvement necessary for the successful Agile execution?
  3. Business value achieved: Based on the type of project how often the business values can be realized by the customer?
  4. Quality: Because of the methodology chosen, Is there any risk in compromising on the quality of the deliverable?

All these questions come to the customer’s mind when they see the change in methodology from traditional to Agile. So answering those for the specific project by building up the strong business case is the key to win the customer confidence.

Product chartering helps in bringing that context to the developer community.

Chartering

We want the community that is delivering the product and/or project to understand the why, how and who of the initiative—

 

Why are we building this software?
How will we judge if it is successful?

Who are the project stakeholders? During a chartering session, we bring the team together to create a common understanding of the product, its vision and its goals. This provides a richer context for all involved and leads to a higher level of engagement for the team members.

Establishing the Why: A chartering session starts with the product owner or business sponsors explaining in a few statements what the product is and why it is valuable. This is often called an elevator pitch and it establishes the why.

Judging the Success Criteria: Next, the team starts a discussion on the success criteria. This can be driven by the product owner or sponsor with the feedback from the rest of the team. This reveals the success metrics and appropriate expectations from the product. The testers will get an idea from this input about what to explore in the system during the testing.

Roles: Finally, we discuss the roles of the overall product community (sponsors and senior management, subject matter experts and delivery team) and engage as necessary. Other items that may be useful to discuss at this point, if the product and team are ready, could include working agreements, iteration length and review process, standup times, etc. This identifies the community and helps identify any potential gaps in understanding or skill.

Chartering happens prior to starting the release planning. The chartering sessions often help the product owner understand any limitations, business constraints, or special considerations that need to be accounted for or monitored during the project.

The main purpose of the chartering is to bring your product community around a common understanding of the vision, goals and work to be done. Structure the chartering discussion in such a way that maximizes the free discussion during the session.

 

Summary

Agile analysis and design start with collecting the requirement and coming up with the product backlog. Agile puts emphasis on showing the working software to the customer as early as possible to the customer so that the requirements are validated at the earliest. This also makes sure that the project team validates the architecture and system design before investing too much time on something which is not working in real production environment. In this chapter, we discussed product roadmap, backlog maintenance in Agile projects, story maps, the process of collecting requirements in Agile projects using the Agile modeling, prototypes, wireframes, personas and business case development and use of chartering.

Chapter 7 Questions and Answers

Question 1. Who is responsible for prioritizing the product backlog based on the business values?

  1. Product owner
  2. Project manager
  3. Lead developer
  4. Tester

Question 2. Which one of the following statements is correct regarding when a deliverable is accepted on an Agile project?

  1. Only senior managers to sign off deliverables
  2. At the end of every time-box/iteration the team should get acceptance of project deliverables from the appropriate stakeholders.
  3. The team should worry about acceptance of project deliverables from the users only during a UAT phase at the end of the project.
  4. All stakeholders are encouraged to sit with the developers during the sprints and provide acceptance then and there.

Question 3. Which one of the following statement is correct regarding a characteristic of the Agile project?

  1. The products produced by an Agile project should be cheaper but of lesser quality than those produced by traditional projects.
  2. The products will be of top quality in Agile projects but will be more expensive than the traditional models.
  3. The product may not satisfy the customer need if produced in Agile way.
  4. The customer’s expectation on the product quality will be met, as customer representative is involved throughout the development process.

Question 4. If a new requirement emerges when an iteration cycle is running, it should be:

  1. Immediately included in the work of the project.
  2. Excluded from the project scope and left until a later project.
  3. Assessed for business value and, if is important to the business, included in the Product backlog replacing less important requirements.
  4. Maintain a list for consideration by the wider group of stakeholders after the project has been completed.

Question 5. In which phase of an Agile project does the customer perform scope verification?

  1. At the end of the project
  2. Throughout the iteration
  3. At the end of the release
  4. When the customer is free

Question 6. Which type of artifact presents the quick and easy visual representation of the project health by showing the remaining work in the project?

  1. Burn-down chart
  2. Burn-up chart
  3. Product backlog
  4. Velocity graph

Question 7. A persona in an Agile project can be thought of as:

  1. The person providing the final acceptance
  2. The most powerful person in the project
  3. The user role to see requirements from user’s point of view
  4. The person developing the system

Question 8. Which one of these below is not a feature of the product roadmap?

  1. Date/content/objectives of each release
  2. Value adding to the customer in each release
  3. When releases are needed
  4. The estimate of the tasks

Question 9. Which of the following is not a valid reason for updating the product backlog?

  1. Findings from the previous sprints
  2. Change in market condition which added/deleted some features (stories)
  3. Technical constraints or findings
  4. Product backlog should never be changed

Question 10. An Agile project team has selected some items (user stories) from the product backlog which will be worked upon in the current iteration. They started to breakdown each user story to task level and estimate the same. What is the team preparing?

  1. Sprint backlog
  2. Release backlog
  3. Burn-down chart
  4. Product backlog refinement

Question 11. Which of the following statement BEST describes the use of the story maps?

  1. To get end-to-end picture of the requirement
  2. To create more task for each requirement
  3. To build rapport with the user
  4. To get early user acceptance

Question 12. Which style of decision-making is best suited during the Agile requirement gathering phase?

  1. Command style
  2. Consensus style
  3. Consultative style
  4. None of the above

Question 13. The estimation of user stories in a product backlog are maintained using

  1. Story point
  2. Days or hours
  3. No estimation is possible in product backlog
  4. Random selection of numbers

Question 14. Which technique do you use to rapidly churn out a good number of requirements?

  1. Delphi technique
  2. Facilitated workshop
  3. Teleconferencing
  4. Send questionnaire to users

Question 15. Which of the following is not the benefit for prototyping?

  1. Early visibility to users
  2. Encourages active participation among users
  3. Gives breathing time to the developers
  4. Increases system development speed

Question 16. A chartering session is conducted for an Agile project team. Which of the following is not the benefit the team will get from the chartering session?

  1. Understand why they building this software
  2. Get to know the project execution methodologies
  3. Understand how they will judge if it is successful
  4. Get to know the project stakeholder

Question 17. Which one of the following is not a characteristic of a SMART requirement?

  1. Specific
  2. Measurable
  3. Maintainable
  4. Achievable

Question 18. In which order the different backlogs are created in an Agile project?

  1. Product backlog, release backlog, iteration (sprint) backlog
  2. Iteration (sprint) backlog, product backlog, release backlog
  3. Release backlog, product backlog, iteration (sprint) backlog
  4. All are created simultaneously

Question 19. Which one of the following statements is true for Agile projects?

  1. Each project stakeholders should attend every requirements workshop
  2. Retrospectives are only conducted at the end of a project
  3. Project manager should facilitate the project’s workshops
  4. The structure of a facilitated workshop will be managed by a facilitator

Question 20. A team is busy in development work inside an iteration. The project manager found that one day the team is engaged in a meeting to discuss the added items, deleted items, and changed items in the product backlog. What is this session called?

  1. Product Backlog Grooming session
  2. Estimation session
  3. Sprint planning session
  4. Retrospective session

Question 21. A project team is progressing with the design, but are not sure whether the architecture will support the features to be developed later. What should the use to confirm their concept?

  1. Expert judgement
  2. Prototypes
  3. Hiring consultants
  4. Contact the product owner

Question 22. The main purpose of business case development is

  1. Get more money from the customer
  2. Start the project without customer approval
  3. Gain stakeholder confidence and project approval
  4. Build the team better

Question 23. Who creates the product roadmap?

  1. Scrum master
  2. Product owner
  3. Project manager
  4. User community

Question 24. When the features are broken into tasks in a sprint backlog, what is the preferable length of task?

  1. 4 to 16 hours
  2. 1 to 8 hours
  3. Exactly 8 hrs
  4. Less than 4 hours

Question 25. While executing a sprint a team member found an additional task for a user story he is working on. What is next course of action?

  1. Update the sprint backlog with the new task
  2. Stop work on the story and move it to next iteration
  3. Inform the project manager that there will be a delay
  4. Ignore the task as the sprint backlog was frozen

Question 26. The status of the sprint backlog tasks should be updated

  1. Weekly
  2. At the end of the sprint
  3. When the team has some free time
  4. Daily

Question 27. Who assigns the sprint backlog items to the team?

  1. Scrum master
  2. Project manager
  3. Product owner
  4. Team members nominate themselves for particular tasks

Question 28. Which of the below is a benefit of creating story map?

  1. Eases the estimation process
  2. Creates more test cases
  3. Plan releases as complete and valuable slices of functionality for maximizing the business value
  4. Motivates the team to get the work done

Question 29. What is the most important benefit of a client participant focus group?

  1. Team gets to know the client better
  2. It ensures ownership from the client on the decision taken
  3. Client makes sure that everyone is present in the meeting
  4. Client will bear the cost of the meeting

Question 30. The main disadvantage of the command style decision making is

  1. One or more of the group members may not agree with the decision and thus will have less buy-in in the decision
  2. The decision is made faster
  3. The decision is almost always wrong
  4. Nobody likes the decision-maker

Question 31. Which technique does the facilitated workshop use to churn out requirements?

  1. Group writing technique
  2. Public speaking technique
  3. Delphi technique
  4. Brainstorming technique

Question 32. In which of the below situation you will use the consultative style of decision-making?

  1. The project manager is very powerful
  2. The group is very knowledgeable and reaches consensus easily
  3. The group does not have the information, education, skills or experience to make a high quality decision
  4. The group does not like to talk to each other

Question 33. Which of the following factors should you keep in mind while prioritizing the user stories?

  1. Value, cost, risk
  2. Value, quality, cost
  3. Time, cost, risk
  4. Time, cost, quality

Question 34. Which of the below is not a valid reason for adapting a project in a way that changes the end product?

  1. Introduction to new competitor product
  2. Discussion with the customer reveals additional requirements
  3. The team decides to do the work differently
  4. Customer altered the internal network that will interfere with the functionality of the end product

Question 35. During iteration planning meeting you came across a story which does not fit into the iteration. What is the best thing to do?

  1. Drop the story from the product backlog
  2. Split the story
  3. Extend the iteration length
  4. Report this to the project manager

Question 36. In Agile project ________ determines how much of the product backlog will be delivered in the current sprint.

  1. Team
  2. Project manager
  3. Scrum master
  4. Testers

Question 37. In which type of report you will find market research data and reasons to initiate a project?

  1. Agile contracts
  2. Prototypes
  3. Persona
  4. Business case development

Question 38. You have to document the staging requirements to scale a scrum project. Where will you document this?

  1. Product backlog
  2. Product roadmap
  3. Retrospective report
  4. Test cases

Question 39. Which of the below practice helps the team to understand what to build

  1. Trust
  2. Sitting together
  3. Real customer involvement
  4. Ubiquitous language

Question 40. Thumbing vote is a quick way to check for consensus. Holding thumb sideways indicates:

  1. I agree
  2. I disagree
  3. I will go along with the group
  4. I don’t want to take part in vote

Question 41. At the end of an iteration, 11 user stories passed all the acceptance test criteria. What will be the status of these stories in the product backlog?

  1. Done
  2. In progress
  3. Incomplete
  4. Ready to be tested

Question 42. What below reveals where the project is going and why it is going there?

  1. Vision
  2. Release planning
  3. Risk management
  4. Slack

Question 43. Which helps the tester to have some idea about what to explore in the system?

  1. Chartering
  2. Release plan
  3. Iteration plan
  4. Black box testing

Question 44. Which of the below is not a type of prototype?

  1. Proof-of-principle prototype
  2. Form study prototype
  3. Visual prototype
  4. Test-driven prototype

Question 45. Following are the guidelines used to prioritize features except

  1. Features most important to users
  2. Features most important to the team
  3. Features that provide value to the customer
  4. Features are that high value and high risks

Question 46. Specify whether the below statement is true—‘Product knowledge is the knowledge about what will be developed and project knowledge is the knowledge about how it will be developed’

  1. True
  2. False

Question 47. The product owner has provided a plan to an Agile team which specifies the high level grouping of the features in planned releases. What is this plan called?

  1. Product visioning
  2. Product roadmap
  3. Sprint plan
  4. User story

Question 48. Which of the below statement is true regarding the product backlog?

  1. All details of the user stories are found in the product backlog
  2. The user stories in the product backlog is at high level and are elaborated as the project progresses.
  3. Product backlog is created at the beginning of the project and then is thrown away
  4. We can skip the stage of product backlog creation

Question 49. An Agile project team is preparing the list of items they will be working in the current sprint. What is this list called?

  1. Sprint burn-down chart
  2. Release backlog
  3. Sprint backlog
  4. Sprint report

Question 50. If there are additional requirements for doing extra regression testing in a user story how you will address that in your sprint backlog?

  1. Get additional tester in the team
  2. Remove the user story from the list
  3. Keep the step of additional regression testing as a separate task and estimate for the same
  4. Ask the product owner for more clarification

Answer Sheet for Chapter 7 Questions

Question Number Answer Question Number Answer
Question 1 Question 26
Question 2 Question 27
Question 3 Question 28
Question 4 Question 29
Question 5 Question 30
Question 6 Question 31
Question 7 Question 32
Question 8 Question 33
Question 9 Question 34
Question 10 Question 35
Question 11 Question 36
Question 12 Question 37
Question 13 Question 38
Question 14 Question 39
Question 15 Question 40
Question 16 Question 41
Question 17 Question 42
Question 18 Question 43
Question 19 Question 44
Question 20 Question 45
Question 21 Question 46
Question 22 Question 47
Question 23 Question 48
Question 24 Question 49
Question 25 Question 50

Answers for Chapter 7 Questions

Question Number Answer Question Number Answer
Question 1 A Question 26 D
Question 2 B Question 27 D
Question 3 D Question 28 C
Question 4 C Question 29 C
Question 5 B Question 30 A
Question 6 A Question 31 D
Question 7 C Question 32 C
Question 8 D Question 33 A
Question 9 D Question 34 C
Question 10 A Question 35 B
Question 11 A Question 36 A
Question 12 B Question 37 D
Question 13 A Question 38 A
Question 14 B Question 39 C
Question 15 C Question 40 C
Question 16 B Question 41 A
Question 17 C Question 42 A
Question 18 A Question 43 A
Question 19 D Question 44 D
Question 20 A Question 45 B
Question 21 B Question 46 A
Question 22 C Question 47 B
Question 23 B Question 48 B
Question 24 A Question 49 C
Question 25 A Question 50 C

Explanations for Chapter 7 Answers

  1. Answer A

    Product owner is the customer representative with most business knowledge and he/she should prioritize the product backlog based on business value.

  2. Answer B

    Agile emphasizes on getting the acceptance of the requirements that are delivered within an iteration at the end of the iteration.

  3. Answer D

    Because of continuous involvement of the customer during the requirement as well as the development process, there is very less chance in Agile projects that the deliverable is too far away from the customer’s expectation.

  4. Answer C

    Product backlog can be updated based on the business value of the new requirements.

  5. Answer B

    The requirement verification is done by the customer either throughout the iteration or at the end of the iteration. The developed features are marked as done once the customer does the verification.

  6. Answer A

    A burn-down chart is a visual representation of the work remaining in an iteration and is easy to read.

  7. Answer C

    Persona technique is used to view requirements from customer’s point of view.

  8. Answer D

    At the product roadmap level the estimate of the tasks are not available. All other are the features on product roadmap.

  9. Answer D

    Product backlog can be changed based on the conditions like point A, B and C.

  10. Answer A

    The team has selected the items to work in the current sprint and is elaborating the sprint backlog.

  11. Answer A

    A story map is created so that the project team as well as the user community is clear about the end to end use of the system.

  12. Answer B

    The consensus style ensures maximum participation from the users and thus is preferred for Agile requirement gathering.

  13. Answer A

    Story point is the relative estimation technique which is mostly used for product backlog estimation.

  14. Answer B

    Facilitated workshops are the best way to churn out large number of requirements rapidly as it helps in collective brainstorming.

  15. Answer C
  16. Answer B
  17. Answer C

    SMART stands for:

    • Specific—clearly states what is required
    • Measurable—to confirm when it has been met
    • Achievable—can be done, e.g., technically possible
    • Realistic—is reasonable, e.g., cost is not prohibitive
    • Timely
  18. Answer A

    Product backlog is created first from which release backlog selects the items for the next release and then from that sprint backlog selects the items for the next sprint.

  19. Answer D

    A facilitator manages the structure of the facilitated workshop.

  20. Answer A

    Throughout the execution of the Agile project, the product backlog gets refined. The session where new items and changes to the product backlog is discussed is called the Product backlog Grooming session.

  21. Answer B

    Prototyping is a quick way of validating the architecture of the team is not sure of the technical capabilities.

  22. Answer C

    Business case represents the viability of the project and thus helps in getting stakeholder support and confidence.

  23. Answer B

    Product owner represents the business community and thus creates the product roadmap.

  24. Answer A

    The preferred length of the tasks is 4-16 hours to make sure that those are not broken too small or too big so that those can be planned and tracked.

  25. Answer A

    The first thing will be to add the task in the Sprint backlog. After that if required the re-planning should happen based on the time available and time required.

  26. Answer D

    Sprint backlog progress status needs to be updated daily so that the burn-down chart can be prepared.

  27. Answer D

    In Agile the team is empowered and they plan and nominate themselves for the tasks.

  28. Answer C

    Story map helps in creating the release plan, which is best aligned with the business need and thus maximizing the business value.

  29. Answer C

    The idea of a focus group is to bring all the stakeholders together and brainstorm. So, the client helps in ensuring that all the parties are present in the group.

  30. Answer A

    Command style decision making doesn’t take into account everyone’s point of view and thus may leave few stakeholders unconvinced because they don’t have a buy-in to the decision.

  31. Answer D

    The main purpose of the facilitated workshop is to brainstorm and churn requirements.

  32. Answer C

    The group members are consulted before making the decision but it is not necessary that everyone agrees with the decision because the group may not have the information, education, skills, or experience to make a high-quality decision.

  33. Answer A

    Product backlog prioritization should take into account three primary items - Value of the item, cost of developing the item, and risk associated with developing or not developing the item.

  34. Answer C

    Change in client need or market dynamics can change the product behavior but the team should not change it as their will.

  35. Answer B

    Very large user stories are difficult to plan and thus should be split.

  36. Answer A

    Planning is done by the team in Agile projects.

  37. Answer D

    Business case provides the information about the importance of the project and the return on investment.

  38. Answer A

    Product backlog contains all the requirements for the project, be it functional or non-functional.

  39. Answer C

    Agile recommends direct customer involvement throughout the project life cycle so that all are clear about the requirement.

  40. Answer C

    Holding one’s thumb sideways means ‘I will go with the decision of the group’.

  41. Answer A

    ‘Done’ness is defined as the passing of acceptance tests.

  42. Answer A

    Product vision provides the visibility of why the product is being built and who is going to use it. The details help all the stakeholders understand the necessity of the project.

  43. Answer A

    Chartering provides the idea of who is going to use the product and why which helps the testers preparing the test plan and cases accordingly.

  44. Answer D

    Proof-of-principle prototype, Form study prototype, Functional and Visual prototype are valid types of prototypes.

  45. Answer B

    Feature lists are prioritized according to business need and not according to the team’s convenience.

  46. Answer A
  47. Answer B

    Product roadmap is the prioritized and grouped set of requirements for the project.

  48. Answer B

    Requirements in Agile projects are evolved with the project and more details are added to the requirements as the project progresses.

  49. Answer C

    A subset of the product backlog which will be worked upon in the current Sprint is called the Sprint backlog.

  50. Answer C

    Every task that needs to be performed in a sprint should be part of the Sprint backlog and be estimated.

Key Terms

Product roadmap This is a plan where the product backlog items are categorized release wise so that the business users come to know what features are getting available at what point of time.

Product backlog Product backlog is the cumulative of all the stories which are yet to be implemented.

Release backlog A release backlog is a subset of the product backlog that is planned to be implemented and released in the coming release.

Sprint backlog The sprint backlog is the list of work the team will work on during the current sprint. At this stage, the features are broken down into tasks, which, as a best practice, should normally be between 4 and 16 hours of work.

Story maps User story mapping is a technique to organize and prioritize user stories. The main aim of user story mapping is to understand the end to end user requirements and stitch them in a logical thread so that users get maximum return on the business value.

Personas Persona creation is a technique of researching and developing a model for the most important customer when you try to see things from customer’s point of view and try to understand their requirement better.