The ProcessThe day started with a quick whiteboard overview of the entire Agile Scrum Framework and this diagram kinda replicates what Gavin the BoostAgile Scrum Master drew for me:
[caption id="attachment_2464" align="aligncenter" width="400"] Source: http://www.softwaysolutions.com/[/caption]
As this was a 1 week Sprint the next step was a two hour Experience Mapping workshop, where we worked through some personas and the ideas on what outcomes the final product will enable people to achieve.
Then into mapping out the steps or activities we currently undertake to achieve the same outcome today (we are focussing on building a product that automates some stuff we do manually at the moment, or don't even do at all). Followed by grouping them into themes.
Then under each theme defining the functions we need to to achieve the theme, and then prioritisation of the functions.
Last thing was to write user stories for each of the must have features, that included how we would evaluate they are delivered successfully.
The important thing with features was to focus on what the outcome was not what the solution would be, which was a struggle for me given I spend so much time defining solutions!
User stories were defined in the format of:
As a <type of user>, I want <some goal> so that <some reason>
So again identified who would do what to achieve what outcome.
The InsightI can see how the Experience Mapping through to User Stories can be used as a way of replacing the traditional Requirements Gathering phase of a Waterfall process. But with a lot more focus on what the outcome would be and how we would validate it was delivered
And importantly I now have one of my major concerns negated, which was if we do lots of little developments (sprints) how do we ensure we come to an outcome. This is achieved in a few ways:
- The Experience Mapping process and the feature definition means you define the total product (albiet at a very high level)
- The Sprint process followed by the review and retro means you can adapt over the project timeframe to make sure you deliver the required outcome vs delivering to the requirements that were defined months ago
- If the project gets canned at anytime then you can always go live with everything upto the end of the last sprint, try doing that in the middle of a waterfall project.
So no different to a tech lead and a project manager you would think, but for me there are a couple of differences in that the roles are kinda of reversed from the norm:
- The Scrum Master who is responsible for making sure the tasks are complete (well the scrum team are self organising another difference but you know what I mean) does not report to the stakeholders, just the Product Owner (very different to a normal project manager role)
- The Product Owner is responsible for defining what is delivered (the product vision, features etc) and is accountable to the stakeholders, which ensures accountability with no where to hide (but very different to the tech lead role)