Conversation ParalysisScrum teaches us that feature requests (user stories) are to be written in the language of the customer (As <some role> I need <some feature> so that I can <get some value>.) These small sentences actually pack a load of information for the technical team reading them and it forces the user to really think about their feature and what they are trying to accomplish. All too often, even the customer doesn't know exactly what they want, so this format helps them to succinctly describe their problem.
The beauty of the user story however is not necessarily the language or format. The user story is actually the place holder for the conversation that needs to take place. The team can then solve the user's problem by talking through the solution with the entire team's knowledge and wisdom at work (all the while conversing with the customer as well).
What is even more beautiful, is that Scrum provides the guide rails that help ensure the team is talking about the problem and not acting as if they are robots on an assembly line. Remember that Scrum is a framework, not a prescriptive methodology. As we go, it places guide rails to help us with our behavior and discipline.
In describing user stories, Scrum helps us to ensure we retain collaboration and teamwork. The more detail that is left out of the story, the more conversation that takes place, and the more conversation that takes place, the better the team and the solution become. Start out with the initial concept, talk about it, make notes, which then brings up other topics and considerations. Various opinions and experiences are injected and the end result should be a well-thought-out solution to a well-thought-out problem.
User stories are usually adorned with acceptance criteria (bullet points that essentially explain to the team how they know they are done). In our organization we use the words "demonstrate" on acceptance criteria to enforce the spirit of Scrum in that the done feature is demonstrable product. The point is to communicate conditions of acceptance for the story, but not eliminate the need for the developers to converse about the final solution. Too often teams can run right down the list of acceptance criteria and start coding the solution as if everything they need to know is in that acceptance criteria.
Ron Jeffries wrote a great post on "The 3 C's" which details the heart of what we were all taking about in our last DFW Scrum Meeting. Gary McCants stated that acceptance criteria are there to guide you, but don't let them paralyze your conversation-ability (if that is a word). Ron describes confirmation as the final deliverable to ensure we hit the mark.
Remember that the conversation takes place over time and that the user story is simply the placeholder for those conversations. Don't write so much detail that you paralyze conversations from happening in your team.
Posted In: Tips,
- Include Requirements & Contribution Sub Types
- User Case Story from Hope Community Church
- Group Search Categories and More
- Account Creation
- Single Sign On Functionality Exposed
- API Communication Value Changes
- API Enhancement: Create and Edit Groups!
- API Enhancement: Requirements Exposed
- Resource Versioning
- Enter Visitor Data via Your Church Website
- Fellowship One & Planning Center Online
- API Libraries and Sample Code
- Building a custom login for your church website using the API
- Roll Foward!
- The Agile Triangle
- Conversation Paralysis
- Picture this, image updates & creates through the REST API
- A REST API double shot : Groups and Events realms
- Increasing Software Delivery by 500%
- Quick people API realm update
- Introducing the new REST API giving realm
- Raising the bar…
- Building a Deployment Pipeline
- The World of Dev Craft
- Running Tests in Parallel with Selenium
- Abstracting Your Code to Remove Duplication
- Documentation in an Agile Environment
- Drowning in Debt
- Intro to Ruby on Rails
- API Strategy & Roadmap
- Staging/Sandbox Environment is Back up!
- Downtime in Sandbox/Staging Environment
- Android & OAuth
- F1 API Static Library with Objective-c
- Programming in F#
- NoSQL: HuMONGOus Benefits (Part 2)
- Our Scrum Team Structure
- SaaS & BI - The History & Future
- Getting Started with Android
- NoSQL: Leaving Schema Behind (Part 1)
- Your Feedback…and a $25 Gift Card!
- A Scrum Ceremony? Is this a wedding or something?
- Variables in PHP
- Data Exchange API Fixes
- F1 Check-in on the iPad
- Be the first to get the news & tips!
- An Introduction to PHP
- Working with Pop Up Windows in Selenium
- List Comprehension
- Source Control: A Time Machine For Your Source Code
- Developer Conference…Lower Price, Same Great Content!
- The Quality Assurance Team
- How does Fellowship Technologies manage complex projects?
- Developer Conference coming in May!
- Sandbox Refresh Complete
- Sandbox Refresh This Week
- Updates coming to the REST API
- Sandbox Environment Down Time
- F1Touch :: Fellowship One On The Go
- Under the Hood
- Sandbox Refresh Complete
- Sandbox Refresh Tomorrow (Oct. 2nd)
- Fellowship One Developer Forums
- Ten Commandments of API Consumption
- REST API Enhancements / Fixes deployed to Sandbox and Production 09.09.09
- Data Exchange URL cut-over complete
- Important Data Exchange URL changes
- Ron Nom Nom
- How to get started using the REST API