Agile Book – Requirements

This is the second in a series of blogs about our upcoming textbook called Introduction to Agile Methods that I have written with Sondra Ashmore.  The first blog spotlighted Roles and our second post was a guest blog by Sondra on Agile in Academics.  I hope these blogs inspire you to want to read the whole book!  Pre-orders are available on Amazon right now – just search Introduction to Agile Methods by Sondra Ashmore and Kristin Runyan. The chapter spotlight for this post concerns Requirements and how they Userstoryare approached very differently in Agile, as opposed to Waterfall.  Within Agile, the terms around requirements include User Stories, Epics, Acceptance Criteria, Personas, Release Management and much more.  The excerpt that I have chosen to share here addresses a particularly challenging aspect of managing requirements and priorities – Customer Specific Code Requests.  First, here are the learning objectives for the chapter.

Learning Objectives

  • Recognize the differences between Agile and Waterfall with regard to requirements gathering and documentation
  • Understand the format used within Scrum for user stories, including epics and acceptance criteria
  • Explore several examples of how user stories are broken down from epics to child user stories and how acceptance criteria add important details to the story
  • Learn how the other methodologies differ from Scrum in their terminology and practices
  • Examine how requirements can be enhanced by using personas or engaging User Experience (UX) designers to better understand potential system users
  • Understand how user stories and Agile development efforts map into a marketplace driven by consumer demands and customer-specific development requests
  • Value the importance of communication and transparency when it comes to requirement specifications and priorities
  • Explore Lean software development and the Lean start-up concepts and how they influence the product development process

Customer-Specific Code

Another complexity with Agile is managing existing customer expectations when they want specific development that they are willing to pay for. This process challenges the Agile principles of iterative development because it is typically time-bound, and scope must be defined and agreed upon before starting the project. These projects tend to be more Waterfall in nature, but there are several Agile techniques that can be employed to improve the experience over Waterfall. First, express the requirements in the user story format; this change alone will lead to more effective requirements discussions and will invite collaboration with the customer. Second, make sure the customer knows that development will progress in a series of sprints, and provide some transparency on what will be included within each sprint. It may be wise to invite the customer to the Sprint review (demo), described in Chapter 8, “Tracking and Reporting,” where the code is demonstrated to the product owner. The customer could then see the progress and may want to make changes to their requirements. If changes are requested, the customer management team may need to execute a scope change to the contract, so the product owner and Scrum team will need to be extremely careful about incorporating customer feedback. To summarize how to handle customer-specific (and paid for) code requests, Table 5.1 presents some dos and don’ts: Table 5.1 Dos and Don’ts of Customer-Specific Code

Do Don’t
Commit to features. Adjust the scope without the involvement of the account management team.
Document the requirements in user story format. Commit to a date that is “optimistic” given current resources and conditions. Make sure that dates can be reasonably met.
Be transparent about development progressing in a series of sprints. Agree to user stories or requirements that are vague in nature or could easily be misinterpreted.
Consider inviting the customer to the Sprint demonstrations/reviews.

Although certain aspects of customer-specific code requests do not fit in an Agile framework, there are ways to manage things effectively by being collaborative and transparent with the customer.

 Conclusion

Every chapter of our book ends with an interview of Agile experts from around the globe and this chapter is no exception.  We are honored to have Ellen Gottesdiener and Mary Gorman who co-authored an excellent book called “Discover to Deliver.”  We hope you enjoyed this blog and are excited to read the rest of the book.

 

Leave a Reply

Your email address will not be published. Required fields are marked *