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 higherfidelity 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/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.
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.
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.
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/