Increasing the Agile mindset and creating higher performing teams can pose quite a bit of a challenge even to the most experienced of agile coaches.
Will endeavor to set up a weekly post with a small collection of hints and tips and gotcha’s to avoid 🙂
“Just Good Enough”
Being Agile doesn’t translate to no documentation. Instead, in Agile Scrum, documentation should be “Just Good Enough“. Traditionally, entire cottage industries are created through the need to document and audit everything. This is not necessarily so true in Agile. Stories and Tasks are documented just enough to cover the delivery of the feature. Once the feature is delivered, it is very rare for anyone to refer back to old stories and tasks.
Having too much documentation will run the risk of becoming mini-waterfall within your sprints.
Epics and Feature Briefs
Epic and Feature briefs are small
Avoid distributing risks and assumptions across these briefs. Instead have a central risk and assumptions area in your wiki/team space and link the relevant epic or feature Id there.
Documenting User Stories
Documenting user stories should follow the INVEST rule and focus on having sufficient information to allow a delivery team to have a conversation with the product owners and break the story down into technical tasks as part of their sprint planning.
I will not explain INVEST here – there are many great articles on the web that can do that significantly better than I can 🙂 The main purpose here is to ensure that there is enough for that conversation to take place.
Gotcha #1: Technical teams may start breaking down their tasks as per the screen wireframes (instead of taking each story). This will result in a disconnect between the stories and the tasks. A screen wireframe may have multiple stories within it, but the team may have difficulty in assigning the right tasks to the right story.
The result will be a single story that will suddenly have a lot of tasks in it and other stories with zero tasks. If you see this, stop immediately, and re-focus the delivery team to work off the stories themselves and not the wireframes in isolation.
It is also useful for the team to have a holistic view of the wireframe screen they are delivering, and possibly superimpose the story cards over the screen. This gives them the overall view of the screen and expected
It is key to review the stories and tasks and ensure traceability between the “what/why” and the “how”.