one criteria is what this article focuses on.
In a blog post in SD Times, Agile 2016: Scrum is not done yet, and neither are you, Christina Mulligan describes the state of the industry through the eyes of Dave West, CEO & Product Owner of Scrum.org. A nice double entedre in the blog post title!
Dave West notes:
"What we see is that ‘done’ is being fragmented across many organizational boundaries; people don’t really get it, there is not a universal definition."This fragmented state of affairs gives rise to another phenomenon, capable of giving a bad rap for the Agile industry. Thus, for example, many software practitioners even discuss about disadvantages of agile.
In the rest of the post, I intend to submit a viewpoint that, hopefully, takes us a little closer to a more organized way of agile planning.
A vertical slice is a user story that is crafted by taking a (vertical) slice through the software stack of the system. (The adjective 'vertical' comes about by the manner most macro architectures are depicted -- end user on top of the picture and the various layers of the software system supporting the end user progressively towards the bottom of the picture. See, for example, an illustration in On the Qualitative Importance of Vertical Slicing in Agile Project Executions).
A collection of vertical slices constitutes a release or a minimum viable product (MVP).
It is useful to keep in mind some of the pitfalls while crafting vertical slices. We can describe these by using a simple model of a web application (after Splitting stories into small, vertical slices):
Once we accept that a vertical slice is a good way to capture end user functionality, the question then becomes: How do we know that we have a good implementation of the vertical slice? This is where the Done criteria becomes relevant. A user story is not completely specified unless it is accompanied with a Done criteria which ensures, when the criteria are satisfied, that the software representing the slice can indeed be made available for a end user (or a proxy) to play with. (Recall one of the tenets of the Agile Manifesto: Working software over comprehensive documentation). If the Done criteria do not assure us that a vertical slice indeed is worthy of end user review, we cannot reliably predict when we can the make the release available! The key thing to note is that we need the Done criteria to assure us that the vertical slice is really done, when the scrum team announces it is done.
With the vertical slices needed for a MVP defined, and their corresponding Done criteria identified, it is time to assess the complexity of implementing each one of the vertical slices. Story points are the abstraction used in the Agile community to assess the work involved in creating the implementation of the story by the scrum team. (It is a function of the scrum team). If the stories are crafted by making use of the INVEST mnemonic, it is generally experienced that stories can be moved around to be worked on in different sprints, during planning certainly, to meet with the goal of producing a shippable product increment every sprint.
So, what have seen here so far for a release or an MVP?
- Identify the functionality needed by a end user of the system -- user story -- in terms of vertical slices.
- Capture the Done criteria for each vertical slice so that, when the criteria are satisfied, the vertical slice can be part of a product increment.
- Assess each vertical slice through the abstraction of story points, and using a representative number for the velocity of the team, arrive at the number of sprints needed.
Mike Cohn. Agile Estimating and Planning. Prentice-Hall, 2006. Kindle Edition.
Colleagues at Zymr, Inc. are helpful participants in my Agile journey.
Some Thoughts on Modeling in Jira, a Commercial Tool
Jira is an agile project management tool that is quite popular in the industry. This section talks about one way of modeling vertical slices in Jira.
All vertical slices can be modeled as stories in Jira. Sometimes, it is sufficient to model the components of the slice as sub-tasks in Jira; other times, not. In the latter case, it is best to model them as tasks and, since tasks cannot be assigned story points, the task's complexity can be subsumed by a user story that is dependent on the task.
If a requirement is not a vertical slice, it is best modeled as a task that feeds into a story.