Module 4 Designing, Planning & Estimating€¦ · backlog to start decomposing high priority items...

© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved

Module 4 Designing, Planning & Estimating

Table of Contents

Module 4 ...........................................................................................................................................1 Study Guide ...................................................................................................................................2

Reading.................................................................................................................................................. 2 Assignment ............................................................................................................................................ 2

Module Overview ..........................................................................................................................2 Outline ................................................................................................................................................... 2 Learning Outcomes ............................................................................................................................... 2

Agile Architecture & Design ............................................................................................................3 Enterprise Architecture Considerations................................................................................................ 3 Architectural “Spikes” ........................................................................................................................... 4

Wireframes & Prototypes ...............................................................................................................5 Business Analysis & User Stories.....................................................................................................7

Creating User Stories ............................................................................................................................ 7 User Story Examples ............................................................................................................................. 8 Tools and Techniques............................................................................................................................ 9 Epics .................................................................................................................................................... 10 Non-Functional Requirements ............................................................................................................ 10

Estimation and Planning ............................................................................................................... 12 Tools & Techniques ............................................................................................................................. 12 Task Definition .................................................................................................................................... 13

Summary ..................................................................................................................................... 15 References ................................................................................................................................... 16


Study Guide

Reading

Required:

• Course module content

• Rubin, Chapter 5, Requirements and User Stories

Recommended:

Leffingwell, D. (2011). Agile Software Requirements, Upper Saddle River, NJ: Addison-Wesley, Chapter 20, Agile Architecture (provided as PDF)

Assignment

Individual Assignment: Wireframe

Module Overview

In this module, we look at architectural considerations for developing our solution. While architecture isn’t

explicitly covered in the Scrum framework, we still take an iterative approach in crafting the design for our

solution. If the team is evaluating a new solution, prototypes and wireframes provide low-cost, low-impact

ways to test our designs from both an end-user and technical perspective. In the prototyping process, we can

create low-to-high fidelity prototypes to communicate and share our ideas. High fidelity prototypes provide a

high impact way to show your users what the finished product could look like before development begins,

giving them the opportunity to provide valuable feedback.

Once we’ve established the general architecture and design for our solution, we can look to our product

backlog to start decomposing high priority items into user stories. User stories are a written description of a

requirement from an end user perspective. The story reflects functionality that they value.

In estimating the amount of work that it will take to complete a story, the team breaks down their product

backlog into story points or ideal days estimates to provide a rough order of magnitude for development

work. Additional considerations include the team’s velocity, a measure of how much work a team can

complete within a sprint.

Outline

• Introduction to agile architectural design practices

• Using prototypes and wireframes to prove out and communicate solution design ideas

• Breaking down a product backlog into user stories

• Understanding methods used to estimate stories • Breaking stories into tasks

Learning Outcomes

The expected learning outcomes for this section of the course are:

• Understand where architectural design fits within an agile project

• Know when to use different fidelity prototypes and wireframes

• Learn how to craft user stories from your product backlog

• Estimate and size your user stories for development

• Decompose your stories into tasks for development


Agile Architecture & Design An area not typically expressed within agile methodologies is the question of architecture and design. In fact,

most methodologies assume that the infrastructure is in place before the team begins development work.

However, for large or complex systems where there is new (or unknown) technology, software, data or other

components, the team may need to take a more agile approach in the design of the underlying system. So

far, we’ve taken the user-centric approach to developing requirements (the “what”), but haven’t addressed

the system architecture (the “how”) of enabling those requirements.

Enterprise Architecture Considerations An organization’s enterprise architecture consists of the processes, data, technologies and customer

interfaces that make up a company’s business operating model. Enterprise architectural models conceptually

define the systems within an organization today and in the future. The role of the enterprise architect is to

help create and promote technology standards (and adherence to standards).

Given that architectural planning and governance will have a significant impact on your agile: What do we do

in an environment where we have new technologies or capabilities not yet defined in our enterprise

architectural model?

Agile methodologies, such as Scrum, assume that architecture emerges throughout the course of the

development. As new requirements or stories are implemented, the architectural design is refactored (a

process of improving design without impacting functionality) and aligned to the enterprise architectural

vision.

Leffingwell (2011, p. 390) outlines eight principles of agile architecture:

• The teams that code the system also design the system

• Build the simplest architecture that can possibly work

• When in doubt, code or model it out

• They build it, they test it

• The bigger the system, the longer the runway

• System architecture is a role collaboration

• There is no monopoly on innovation

• Implement architectural flow

There are two points of view on architectural approaches in agile development. One on side we have what’s

called “BDUF” or Big Design Up Front, the other is emergent design (also called NDUF or No Design Up Front).

Agile Sherpa (n.d.) defines an emergent design strategy as follows:

“With Emergent Design, we start delivering functionality and let the design emerge. We take piece of

functionality A and implement it using best practices and proper test coverage. We then move on to

delivering functionality B. Once B is complete, we look at what A and B have in common and refactor out the

commonality, allowing the design to emerge. This process continues as we continually deliver functionality.

At the end of our release, we are left with the smallest set of the design we need, as opposed to the design

we could have imagined up front. We end up with a smaller code base, which naturally has less room for

defects and a lower cost of maintenance.”

But we shouldn’t think of architecture in terms of absolutes. Design inevitably evolves over time, but forward

planning is often an imperative. Taking the extremes of too much and no design can result in a lot of rework

down the road. Our ability to continuously refactor is dependent on other organizational constraints.


Architectural “Spikes” Quite often a team might be faced with a new architecture, design or technology that they need more

information on before they can begin work on a particular story. Within agile, this exploratory activity is

called a spike (although you may hear similar terms to describe it, such as prototype, proof-of-concept,

experiment, etc.). Shore and Warden (2008) describe a spike solution as a technical investigation. The spike is

a small, time-boxed experiment to research possible solutions to a problem. Here are some other reasons to

consider a spike (Leffingwell, 2011, p. 114):

• Research to help the team become more familiar with a technology or domain

• To analyze a story with a lot of unknowns so that it can be estimated appropriately

• To explore or prototype areas with inherent technology risk

• To explore and understand functional risk, where the story is clear, but it is not clear how the system

design supports the story from a user interaction perspective

Some teams capture the spike as a separate user story and address it within a sprint. If the team knows

enough about the design considerations in advance, the spike may take place outside of the sprint as part of

the release planning activities. Since spikes take away from development time, they should be used sparingly.

The team may even want to include the spike on the backlog so that it is transparent to the customer and

product owner how time is being spent. Teams can use the following guidelines when determining whether a

spike is necessary:

• The output of your spike is information that may result in a decision or some other solution/story

clarification. The spike should be time-boxed and conducted in a way where the team gathers just

enough information to make a decision. Include acceptance test criteria so that the team can

demonstrate that the spike has accomplished its objectives.

• Reserve spikes for larger questions or problems. Each user story likely contains small unknowns and

the team should learn to manage those unknowns within the confines of the sprint. Save your spikes

for big questions.


Wireframes & Prototypes So far, we’ve done a lot of work to understand what’s important to our customers, ideated around potential

solutions to solve for their needs, prioritized those ideas, and written some user stories. Often, we need a

way to bring our idea into the physical world so that we can increase our users’ confidence in our idea’s

desirability, feasibility, and viability without making a large investment in time or money.

We can do that through prototyping. A prototype or wireframe is simply a mockup or model that helps us

visualize and communicate our ideas. It can be something as simple as a sketch on paper or a more

sophisticated working model. The value is in our ability to iterate through a design concept and get feedback

quickly.

Prototypes represent a working mid- to high-fidelity view of the solution and provides the user with an idea

of what the finished project might look like. The prototype mimics the interaction between the end user and

the interface, but while it may resemble a final product, it’s mostly for show-and-tell. Prototypes are great for

showing your users what the finished product could look like, and lets them react to the solution and provide

feedback before actual development begins.

Both wireframes and prototypes are mockups of your final design. How far you go with them depends on the

amount of time and budget available to the team prior to the start of development. They can be excellent

communication and design tools for application development.

Let’s take a look at some of the more common ways design teams visualize their concepts:

Paper Prototyping Paper prototypes are a great way to get started with some low-fidelity visuals of your concept

design. A technique often used in paper prototyping are storyboards: A sketch of how a user

interacts with your concept. Storyboards help us visualize an experience from the user’s point of

view, showing how the user interacts with the concept along a timeline. A storyboard can be

valuable in providing additional user context, similar to customer journey maps. Paper prototypes

are easy to share and get feedback on before you spend too much time in formalizing a higher-

fidelity design or digital prototype.

Google on Rapid Prototyping: Part 1 Paper Prototyping

https://youtu.be/JMjozqJS44M

Digital Prototypes Digital prototypes in the form of a wireframe provide a higher-fidelity representation of your design

in a digital tool. A wireframe may illustrate the structure of the application, the layout design,

content or information hierarchies, functionality and behavior. Wireframes are commonly used in

web and mobile site design to illustrate how an end user might flow through the site.

Wireframes can be developed for a variety of back-end or front-end development purposes: Graphic

designers might use a wireframe for user interface design, or the development team might sketch

one out to demonstrate functionality. Wireframes are commonly developed in digital wireframe

applications such as UXPin, Balsamiq, Axure, Sketch, etc. Most dedicated wireframing tools support

interaction design and user flow using static content.

Google on Rapid Prototyping: Part 2 Digital Prototyping

https://youtu.be/JMjozqJS44M


https://youtu.be/KWGBGTGryFk

Native Prototypes Native prototypes represent a working mid- to high-fidelity view of the solution and provides the

user with an idea of what the finished project might look like in an actual software development

environment. This could include coding out some of the concept or creating skeleton designs on an

existing platform.

Google on Rapid Prototyping: Part 3 Native Prototyping

https://youtu.be/lusOgox4xMI

Material Design If you're interested in design frameworks for web and mobile, Material Design is Google’s visual design

language for web and app development. The goal of Material Design is to synthesize principles of good

design with technology. Apple also publishes design guidelines for apps across Apple products. Check

out the 2018 Apple Design Award winners.

https://youtu.be/KWGBGTGryFk

https://youtu.be/lusOgox4xMI

https://material.io/guidelines/

https://developer.apple.com/design/

https://developer.apple.com/design/awards/


Business Analysis & User Stories In a waterfall project management methodology, requirements are defined upfront in the project cycle.

Many organizations capture and document formal requirements based on a series of workshops or

interviews in project initiation. However, throughout the project, business needs may change or need to be

refined. Change in a waterfall project is often managed through a complex change management process that

has the impact of discouraging change (either because the process itself is too complex or restrictive). The

unfortunate result is that at the end of the project, the application that’s delivered may not have the

required functionality or is no longer relevant. In our agile project, we address requirements gathering in a

different way, by capturing information as it emerges in the form of a user story and working side by side

with our customers to ensure we're delivering frequent functionality that adds value.

Creating User Stories User stories are the agile representation of a requirement. What makes a story different is that it is a brief

statement that describes functionality that is important to a user. The user story incorporates what you want

to do, who it benefits, and why it’s important. The story does not prescribe how the work will be done.

Video: How to Write Good User Stories: https://www.youtube.com/watch?v=tKSUokG3Y0w

User stories typically contain three key elements:

• A written description of the story used for planning and a reminder (the “card”)

• Conversations about the story that serve to provide story details (the “conversation”)

• Acceptance tests that document details that are used to determine story completeness (the

“confirmation”)

The Card

In the agile world, some co-located teams’ user stories are documented on hand-written note cards and

made visible to the entire project team. The purpose of using a notecard is to keep the story contained

and to serve as a representation, not documentation, of a customer requirement. More typically, the

team will use an agile project management tool, such as Atlassian’s Jira (www.atlassian.com),

VersionOne (www.versionone.com) or Rally (www.rallydev.com), just to name a few. These tools

facilitate the capture and sharing of user stories.

The Conversation

The conversation helps ensure that the requirements are properly discussed and communicated in a

high-bandwidth manner. The conversation provides fast feedback, facilitating a shared understanding of

the business requirement.

The details of the requirement are elicited through additional conversations or dialogue between the

development team and stakeholders. These conversations take place through the life of the user story,

from the initial capture, refinement, estimation, sprint planning, and sprint review.

The Confirmation

The user story also contains confirmation in the form of acceptance tests that clarify the behavior of the

requirement. This helps the development team understand the criteria on which the feature should be

built and tested and determines the completeness of a story from a user perspective. The team may have

many more technical tests associated with the story that are transparent to the customer, but our

initial focus is on what’s important to the customer. We capture these in the form of acceptance

tests.

https://www.youtube.com/watch?v=tKSUokG3Y0w


Acceptance tests allow the team to verify that the feature works as expected by the customer. The

customer defines the test: You don’t want to write tests that execute correctly, but don’t provide the

functionality that the user has requested. The process of developing acceptance tests is iterative;

additional tests may be added to the story prior to development. As new details are identified, tests are

added.

The product owner retains responsibility for defining product backlog item acceptance criteria. The

acceptance criteria represent the conditions under which the product owner is satisfied that functional

and non-functional requirements are met. The product owner may write the acceptance criteria, but

more frequently may enlist subject matter experts or expert users to assist with the process. Acceptance

criteria should be verified during sprint execution, not during the sprint review. When features are

tested during development, the product owner can help identify mistakes and/or gaps in understanding.

User Story Examples A template for the user story may include a user role or persona, what that user wants to achieve, and

why that capability is important to the user: “As a <<user type>> I want to <<do something>> so that I

can <<meet goal>> .”

Let’s consider a project where our goal is to develop a conference website for the Project Management

in Practice (PMIP) community at Boston University. Sample user needs might start out with:

• Prospective attendees and registrants can access the conference agenda.

• Attendees can register for the conference.

• Attendees can submit personal development unit (PDU) credits after attending the conference.

• In user story format, they would look like this:

• As a prospective attendee, I would like to access the conference agenda so that I can see who

the speakers are.

• As a prospective attendee, I would like to register for the conference so that I can attend.

• As an attendee, I would like to submit PDU credits for attendance so that I can renew my

project management certification.

User stories reflect functionality that will be valued by end users and are not technical in nature – they

don’t describe “how.” These are examples of inappropriate user stories:

• The website will be developed using WordPress.com.

• The website will use Secure Socket Layer (SSL) protocol to connect to PayPal for payment.

While this information may be critical to the development of your application, the user story expresses

the functionality in a way that is meaningful to the customer. The items listed above would be

development tasks tied to the user story.

In our PMIP example, our user story may have the following acceptance tests and reflect the

expectations of the customers interacting with the system. Acceptance tests provide a great way to add

detail to a story.

• Story: As an attendee, I want to pay for the conference using an online payment method, so that

I can easily register.

• Tests:

• Test with PayPal.


• Test with Visa and MasterCard.

• Test card expiration dates.

• Test with invalid card numbers.

At this point our stories are still at a pretty high level, which is fine as you’re starting out. We’re

capturing enough detail at this point to develop a shared understanding of the customer requirement

and create a high-level estimation.

Defining requirements requires equal participation from people who can see the project from both the

technology and business perspective. When participation is unbalanced, business functionality is often

defined with little thought to technology practicality, or developers may define a solution that is

technically perfect, but may not meet business needs.

Tools and Techniques Characteristics of a good user story can be defined by the INVEST acronym (Wake, 2003). Stories should

be:

• INDEPENDENT: Stories should not overlap in concept so that they can be scheduled or

implemented in any order.

• NEGOTIABLE: Details are created by both the customer and developer during the development

period. A user story will capture the spirit of the feature, not the details. As the team begins

work, additional information or clarification will be added, but it is not necessary for

prioritization.

• VALUABLE: The story must be valuable to the customer. Developer concerns must be framed so

that customers or end-users can understand the value. Avoid stories that are only valuable to

developers.

• ESTIMABLE: The story needs to be the right size for a high-level estimation, which will assist the

customer in prioritizing where the story will fit in during an implementation.

• SMALL: A story will generally encompass no more than a few weeks (or days) of work effort.

Smaller stories tend to be more accurately estimated.

• TESTABLE: The test is critical in ensuring that the feature/functionality delivers as expected.

Stories without tests may be often poorly defined or understood by customers.

Getting the hang of writing good user stories is an art and it will likely take your team a few iterations to

capture the information needed to begin development work. Cohn (2004) points out some story

“smells”:

• Watch out for stories that are too small as they may cause problems with scheduling and

estimation. Look for opportunities to combine stories where you can identify

interdependencies.

• Interdependencies will also cause problems with iteration planning. If the stories are small,

combine them; if they are large or right-sized, try and split into layers of functionality.

• As with traditional projects, “goldplating” – or the overdevelopment of a feature – can cause

troubles. Only develop what is required.

• Avoid too many upfront details. This can be challenging for teams that are just switching over to

agile methodologies from waterfall. The purpose of using a notecard to capture a story is to


keep the amount of detail to a minimum. Remember – it’s a reminder to have a conversation,

not create documentation.

• Don’t make early decisions on the user interface (UI). UI assumptions create constraints on

functionality.

Epics When you have a big story, it’s called an epic. In our PMIP project conference website example, let’s use

the following user story:

• End-users can register for the conference.

But do they have to be members of a PMI chapter? Do they have to register on the site before

registering for the conference? How will they pay for their registration? Is there more than one

registration option? There are many details that need to be addressed, and they can be broken down

into smaller stories when it becomes important to work on this functionality.

The point is not to plan for every single detail or contingency, but provide the right level of detail for

planning. In fact, epics don’t need to be broken down until the team is ready for the story in an iteration

planning cycle. Keep in mind that the user story serves as a “conversation” point between the end-users

and the developers, and the conversation is had when the details become important. Too much detail

written into the story may imply that no further discussion is needed, when in fact the opposite may be

true. An epic provides a good overview of what the project is about, but it’s too big to work on. The next

size stories might be classified as features, but are still too big to be completed within a sprint. When the

stories get to the level where the team can estimate the work effort in days, they can be moved into a

sprint. The final breakdown of the story is the task, which can be estimated in hours and completed by

one or two people.

Non-Functional Requirements Non-functional requirements (NFR) represent system constraints and are important in the development

of the product, but may not explicitly meaningful to an end user but has a huge impact on user

experience. NFRs typically encompass qualities of a system, for example, usability, performance,

maintainability, etc. Tests can to be constructed to evaluate these qualities throughout the project, but

we need a way to illustrate the value of the NFR to our customer. NFRs are often nonnegotiable,

meaning that they are not optional requirements that can be left out or deprioritized.

Some agile teams create technical stories to cover the NFRs. The technical stories are included on the

backlog with the other user stories. Other teams include NFRs as constraints or tasks within a user story,

include it as part of the customer acceptance criteria or incorporate it into their “definition of done” (i.e.

work that must be completed to close out a sprint). However, story-level NFRs should only apply to a

specific story. NFRs that apply to the system should be captured separately (it is unlikely that you can

optimize system one story at a time).

Pichler (2013) recommends capturing NFRs as “constraint stories,” with the qualities of the constraint

listed as acceptance criteria. The important component here, as with all acceptance criteria, is that it

must be testable.

Performance Constraint > Acceptance Criteria

As an <<end user>> I want a <1 second response when I click a submit button.


• The time between submit and response should be <1 second.

• 100 users active on the system.

As you can see, there are many ways to address NFRs, but the recommended best practice across the

agile community is to minimize purely technical requirements and find a way to incorporate them in a

context that is meaningful to the end user.


Estimation and Planning Estimation and velocity play important roles in the agile planning process. This section will look at the

different areas of estimation, when teams should estimate, popular estimation methods, and a team’s

velocity as an input into the planning process.

After project approval, the Scrum team starts grooming the product backlog and providing more granular

levels of estimates, often in a numeric form such as story points or ideal days. The product backlog

estimation process takes place in an estimation meeting as part of release planning, but can also happen as

part of product backlog grooming throughout a sprint. Remember that the team is not providing detailed

estimates or getting detailed requirements at this point – this is still a fairly high level of estimate.

As part of product backlog grooming and sprint planning, the team is refining the backlog items into stories

that can be broken down to the task level. Tasks are broken down into hourly estimates, reflected as ideal

hours (effort-hours, man-hours, etc.). An ideal hour estimate reflects the amount of time it would take to

complete the task without interruption.

Tools & Techniques Scrum and other agile methods recognize that people are not good at predicting absolute estimates,

especially when creating a new product or system. Scrum doesn’t dictate that teams use a particular method

or measurement for estimation. However, the most common units are story points and ideal days. Story

points are an arbitrary unit of measure that the team can use to define the magnitude of a product backlog

item. Story points are useful for expressing factors of complexity and size into a relative size measure. This

makes it easier for the team to compare the level of effort between stories. To keep it simple, many teams

treat a story point as an ideal day of work.

An ideal day is defined as a full work day with no interruptions. Imagine it in terms if you sat at your desk for

eight hours and nobody bothered you (and all you did was work!). By representing an estimate in ideal days,

teams can be cognizant of the other things that happen during the day to disrupt work, and factor that time

into the estimate. While a story might be estimated as two ideal days, those two ideal days may be

equivalent to three calendar days due to normal disruptions in work. Eventually, the work effort will need to

be broken down into actual time, but starting with ideal time is simpler as the team begins the estimation

process.

The team owns the estimation process. Story points reflect the effort associated with the story from the

development team’s perspective. Each team’s process and definition will be unique to their project.

Customers participate in estimation by answering questions that the development team has about a

particular story, but they are not allowed to provide input into the estimation process (remember the story

about the chickens and the pigs!). The estimates should reflect the team’s definition of done, and include all

activities associated with that (coding, testing, customer conversations, etc.).

There are many techniques that teams can use during the estimation process. We’ll look a few of the more

popular methods:

Relative Sizing The concept of relative sizing in estimation is important. Scrum utilizes a comparative method of relative

sizing in the estimation process. One of the relative sizing methods is called affinity estimating. This

technique provides a rapid method of estimating a product backlog. Using t-shirt sizes (S, M, L, XL, XXL) or

Starbucks coffee cup sizes (short, tall, grande, venti, trenta) are popular measures for affinity estimates.

Stories can then be grouped according to their size and gives the team a nice visual representation that


allows them to compare within the size groupings (for example, do we really think Story A is the same size as

Story C?).

The process of evaluating stories against each other to baseline sizing estimates is called triangulation. Let’s

say that the team estimates Story A at six story points and Story B at three story points. Is Story A really twice

the effort as Story B? This process of triangulation allows the team to verify that their definition of a story

point is consistent and not drifting through the estimation process. Scrum teams can triangulate their stories

as they estimate, regardless of the scale or method used.

Planning Poker Many Scrum teams use an estimation technique called Planning Poker, a form of the top-down estimation

method known as Wideband Delphi. The team discusses the details of the story, any assumptions or

constraints, and arrives at a common understanding. Planning Poker helps the team more accurately group

items of similar size. The first input into the process is the sizing scale that the team will use for assigning

estimates. Since the goal is relative sizing, the scale generally does not include a full number range, but

instead a sequence that may have more numbers at the smaller end and less on the higher end. A scale called

the Fibonacci sequence is often used.

The Fibonacci sequence is a naturally occurring sequence found in nature, reflecting how things get bigger.

The Fibonacci sequence begins with 0 and 1, and each subsequent number is the sum of the previous two

numbers, giving us the following scale: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144...etc. The sequence is useful in

estimation as it can help teams avoid being too precise with their estimates.

Teams may also choose to create their own estimation scales and constrain them to a specific set of values

(i.e. 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 80). The larger the estimate, the less likely it is to be accurate. If the team is

analyzing an epic, it’s more useful to know that it’s a 40 or an 80, versus a 79 or an 80.

Check out Mike Cohn’s video on planning poker: https://www.youtube.com/watch?v=MrIZMuvjTws

As an Input to Organizational Planning While estimation assists the team with understanding how much work it can take on in a given sprint, it

provides key inputs into the organizational planning process. Most companies don’t have an unlimited

budget or amount of time to deliver a product or system, so the initial estimates created by the team are

often used to calculate budget and duration. Once the size of the project has been determined in story points

or ideal time, the work effort can be calculated in hours or person days based on team availability and

capacity (also called velocity). That effort level is converted into a schedule that factors in team size,

resources and known dependencies. Costs can then be calculated by applying resource rates and any other

project cost elements.

Estimates should always be provided in ranges as an indicator of the team’s confidence level in the estimate.

This is critical for managing stakeholder expectations. As an example, the team might say that the labor costs

for the project might cost between $400k and $450k. The more certain the team is the narrower the

estimate.

Task Definition The team decides what tasks need to be accomplished to complete a product backlog item. While managers

and product owners may provide input into task-level work (by defining the scope of the feature and the

acceptance criteria), they must trust and empower the team to define and organize the completion of that

work.

https://www.youtube.com/watch?v=MrIZMuvjTws


The nature of the business requirements may also influence how the work is completed. For example, if the

team needs to deliver customer-ready work in a production environment, there may be more work effort

involved for customer-readiness. If there are specific technical decisions made that have business and/or

financial consequences, they need to be taken into account in a way that makes sense for the business. These

types of requirements would be included in the team’s definition of done.

Teams should decompose stories into tasks that can be completed in a few hours. The definition of tasks at a

granular level helps enforce discipline to develop and deliver small increments of functionality. Below are

examples of tasks for the team to consider – some of these may be encompassed in the definition of done

and would be incorporated in every story:

• Story design elements: Task for any additional white-boarding or discussion needed around story

implementation

• User interface elements: Task for defining the user interface and any specific methods used to

implement the story

• Create unit tests: A task for creating unit tests

• Create acceptance tests: A task for writing acceptance tests to determine the “doneness” of the

story

• Non-functional requirements: Tasks for attributes such as security, performance, usability,

testability, maintainability, extensibility and scalability

• Code review: Peer review of production code

• Code refactoring: Tasks for restructuring of code in an efficient manner

• Mock interfaces or prototypes: Tasks for creating mock interfaces or prototypes so the team has a

working model to validate against

• Exploratory testing: Ad hoc story testing for non-functional requirements

• Bug verification and fix: Allocating the appropriate time for validation and verification

• Internal team demo: Once a story is complete, the team should take a few minutes to demonstrate

the story

• Documentation: Tasks for updating Wiki or document repository with story design and findings

• End-user documentation: Tasks for creating and updating any required reference or training material

Cohn (2004) recommends the following guidelines for task decomposition:

• If one task of a story is difficult to estimate, separate the task from the rest of the story

• If tasks can be easily completed by separate developers, then split those tasks

If there is benefit in knowing that part of a story is complete, then break that part out as a separate task.


Summary Architectural considerations are important in agile projects. Depending on the complexity and scale of the

project, agile teams need to evaluate approaches for emergent design and Big Design Up Front (BDUF).

Knowledge gathering spikes can be used to test out new technologies or designs, but should be used

sparingly by the team. If the team is working on a completely new design or application, storyboards,

wireframes and prototypes are all good techniques to use to create a shared understanding of the project

deliverables and get early feedback from your customers.

Most design teams iterate through the different levels of prototypes, starting with a paper design, getting

feedback, adapting, and then moving into higher-fidelity digital and native prototypes. For each level of

prototype, while it may resemble a final product, it’s mostly for show-and-tell. Prototypes are great for

showing your users what the finished product could look like, and lets them react to the solution and provide

feedback before actual development begins.

Functionality is described in the form of a user story: a written description of the requirement from the end

user perspective. User stories reflect functionality valued by end users. Large stories with little detail are

known as epics. Epics can be decomposed into smaller stories as functionality is prioritized. Acceptance tests

round out the story and provide the team with details that confirm story completeness. When dealing with

NFRs, provide them in a context that adds value to the user.

Within the product development lifecycle, there are three primary areas where estimation takes place:

portfolio, product and sprint planning. Teams often breakdown product backlog items into story points or

ideal days, relative measures of estimate that provide a rough order of magnitude for development work.

The estimation process includes techniques such as relative sizing, affinity estimating, and Planning Poker.

Once the team develops initial estimates they can calculate their velocity, or ability to complete a certain

number of story points within a sprint. Velocity provides a way to estimate total project duration. Teams can

increase their velocity by improving processes over time. The estimation process is an important input into

organizational planning: total story point estimates, velocity and resource costs can be used to calculate total

project duration and cost.


References Agile Sherpa (n.d.). Emergent Design. Retrieved September 15, 2015 from

http://www.agilesherpa.org/agile_coach/engineering_practices/emergent_design/

Cohn, M. (2004). User Stories Applied for Agile Software Development. Boston, MA: Pearson Education, Inc.

Leffingwell, D. (2011). Agile Software Requirements: Lean Requirement Practices for Teams, Programs and the

Enterprise. Upper Saddle River, NJ: Addison-Wesley

Pichler, R. (2013, March 13). Nonfunctional Requirements. Retrieved September 15, 2015 from

http://www.romanpichler.com/blog/agile-nonfunctional-requirements/

Shore, J. & Warden, S. (2008). The Art of Agile Development. Sebastopol, CA: O’Reilly Media

Wake, B. (2003, August 17). INVEST in Good Stories and SMART Tasks. Retrieved from:

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Module 4 Designing, Planning & Estimating€¦ · backlog to start decomposing high priority items...

Documents

Transcript of Module 4 Designing, Planning & Estimating€¦ · backlog to start decomposing high priority items...