Here are some good practices about communication within an Agile project.
There are some general rules about stories. A story:
- can't be started if it's not estimated
- can't be estimated if it's not clear enough
- can't have a description that's not approved by the client (except chores)
- can't be estimated by a single developer
- should have an acceptance criteria
- should have an user case
- is accepted by the client when it's in production and working
- is delivered by a QA professional
- is finished by developer when it was tested by him in staging
A story is a contract between the client and us. A description such as "I need a way to see how many dealers we have" is not a story, it's a need. A story should be able to be read 6 months later and cause no doubt in its owner.
Do you know why having clear stories is so important?
- subjective stories increase the risk of having to rework the feature due to misunderstandings, which causes a lot of frustration and stress in developers, decreasing their productivity and will to contribute over time
- undefined stories increase the time spent back and fourth in research, causing money to be wasted
- unclear stories are left to the developer's interpretation and will likely not be delivered as expected by the client
- unclear stories can't be estimated correctly, which causes the velocity to have false values and betray the client's strategic plannings
- a false velocity value induces developers to promise things they can't and won't deliver
Here's a simple example. See this story, which was started but didn't have information at all. In this case, it's just a hunch of what has to be done. In that case, the client can change the requirements endlessly, while the developer will have to catch the changes on the fly, making any estimation worthless.
Before the details about how to write stories, let's define the lifetime of a story:
- client/QA/PM/developer creates a story in the Icebox
- once story is ready to be reviewed, a label needs estimation is set
- developers estimate stories in the icebox with that label
- client moves estimated feature stories into backlog according to its priority. Client doesn't need to wait for bugs to be estimated, they can go into the backlog right away
- developer picks story and clicks Start
- developer finished story. Once it's in staging and tested by developer himself, he clicks Finish (not before testing in staging)
- QA tests the story in staging. Is it working? Click Deliver. Delivered stories are ready to be deployed to production.
- weekly deployment to production
- client tests stories that are in production by clicking Accept and Reject. He accepts those that are working as expected and can be deployed.
In the case a feature is deployed and working as described in the story, it has to be accepted. If the client realizes a change needs to be made, we leave it accepted (given it was completed as expected), and a new story is created to change/add what wasn't present in the previous story. This way, we can keep track of velocity of the team regardless of the direction of the project.
Ideally, a story should never be changed once someone started working on it.
Components of a feature story:
User case: compulsory for feature stories. This is a title that represents what needs to be done from the perspective of the user.
- Example 1: "As admin, I want to manage ad types per campaign instead of globally"
- Example 2: "As admin, I want to click a button and start the static ads generation"
You can write this as the title of the story and it'll increase visibility:
Acceptance criteria: compulsory. It's a list of things that need to be done. Each item must be written from the perspective of the end-user in such a way that anyone else (including non-technicals) can test it after reading, even months later.
The more specific in terms of buttons/visual components you can be, the better. He's an example of an acceptance criteria:
"user should click on a button and the app will generate the static ads and push them to Google" "user shouldn't see an active checkbox per ad template."
- Good example: https://www.pivotaltracker.com/n/projects/105667/stories/58722966
- Bad example: http://f.cl.ly/items/2h0G1H1x142K2Q16002X/doubt.png (here, Cristina doesn't know how to test it because the story isn't well defined
Technical details: this is where you speak your developer language. It's irrelevant to the client to read this part.
- Good example: https://www.pivotaltracker.com/n/projects/105667/stories/58722966
- Bad example: https://www.pivotaltracker.com/story/show/55745776 (the client will read this and have no clue what it's about.
Background: this contains the reason why the story has to be done and usually includes a business justification. Although not compulsory, the reason why this is present is that if there's any doubt somewhere else, this high level section will shed light on those questions and avoid wasted time.
- Good example: https://www.pivotaltracker.com/n/projects/105667/stories/58722966 (here, it was called Business Justification)
When writing bugs, you have to:
a) specify every step you took so a developer can reproduce the bug. Eg.
1) go to http://staging.seo-platform.haystak.com
2) enter email and password
3) click button X
Expected: Dealer name is all caps
Actual: Dealer name is downcased
b) try to include screenshots when it's a bug in the user interface
c) if it's a technical bug (e.g OAuth), describe how the client can test it, e.g
Test criteria
a) Login into staging. If it's logged in, it means this store is completed and working fine.
d) if it's a bug in the user interface, include what browser (e.g Internet Explorer, Chrome, Firefox) you were using and what version. There are some browser versions that break the Web standard and could cause unexpected errors.
Everything you say during standup should be spoken in the language of the client.
Saying "I'm working on Circular Dependency problem" means nothing in a business perspective. "There is a weird problem in how code is loaded, I'm investigating that" can be understood.