Agile Planning: Vertical Slices, Done Criteria & Story Points.

Introduction
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.

Vertical Slicing
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):

Done Criteria
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.

Story Points
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.

Concluding Remarks
So, what have seen here so far for a release or an MVP?

1. Identify the functionality needed by a end user of the system -- user story -- in terms of vertical slices.
2. 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.
3. 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.

A book that has influenced this post is:
Mike Cohn. Agile Estimating and Planning. Prentice-Hall, 2006. Kindle Edition.

Acknowledgements
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.

On the Qualitative Importance of Vertical Slicing in Agile Project Executions.

ertical slicing is quite frequently talked about in agile communities. There are good illustrations of this approach using the cake metaphor.

What is the fundamental value of the vertical sliced approach in software development?

What if Healthcare.gov Development Were Managed using Scrum?

In a Forbes' article, HealthCare.gov Diagnosis: The Government Broke Every Rule Of Project Management, the author lists key reasons why the project failed:

1. Unrealistic Requirements
2. Technical Complexity
3. Integration Responsibility
4. Fragmented Authority
5. Loose Metrics
6. Inadequate Testing
7. Aggressive Schedules
8. Administrative Blindness

Agile Estimating and Planning: A Book Review - Section I.

Why write a review in 2013 about a book published in 2005?

Because, Mike Cohn's book, Agile Estimating and Planning is such a book that lays out the philosophy behind agile planning very beautifully, while leading the reader through day-to-day activities.¹

And, as much as I tried to keep the review short, I did not succeed: There are so many nuggets of valuable information throughout the book that I justified making an elaborate review, and decided to publish the review in multiple sections. This post is the first of those.

If your agile development environment already has a set of tools predetermined, such as Rally Software or Jira Agile for example, your day-to-day approach to managing the development may already be somewhat predetermined by the software tool. However, whether you are in such a predetermined environment, or in a pristine environment with possibly no tools other than Microsoft Office, you'll need to recall the basics crisply, and Mike Cohn's book is one excellent reference source.

On Universal Applicability of the Scrum Framework.

Meetup Announcement. (Click to go to Meetup page).

If you listened to Jeff Sutherland on the July 16 talk on "Scrum: The Future of Work", you cannot but walk away with the feeling that scrum methodology is more universally applicable than software development, but the rest of the world is yet to discover that fact. And, his enthusiasm for Scrum's applicability not just in Software Development, but in other parts of Enterprises, in Government, in non-profit organizations, etc., is contagious. Scrum and the Grameen Bank, the Nobel Prize winning microfinance organization?

SV-ALN Meetup: Be Agile. Scale Up. Stay Lean.

Dean Leffingwell

If you are already familiar with the concepts of Agile methodology at the team level, following Dean Leffingwell when he elaborates on the scalability of the Agile framework is a breeze. Such was my experience yesterday when he presented the Scaled Agile Framework™ (SAF) at the SVALN meetup.

The primary ambition of the Scaled Agile Framework is to take the Agile principles to be effective at the enterprise level.

We have already seen several approaches to utilizing hierarchy in using the Agile methodology at the team level. This framework takes the hierarchy, from a team or a project level, to program and portfolio levels, and recognizes the need for non-functional requirements (NFRs), in addition to the user stories that a user would definitely interact with, and recognizes business epics and architectural epics.

On Managing [Complexity in] Systems Development

Modern society invariably tends to need complex¹ systems. (If a system is too 'simple', there may not be any market for it). Consider, for example, some of the successful products in present times:

1. Smartphones such as the iPhone, the Samsung Galaxy
2. Tablets such as the iPad, Google Nexus 7
3. Electric cars such as the Tesla

Each one of the foregoing has, in addition to software, a collection of parts, in several levels of hierarchy, in creating the end user product. (A blog post makes an interesting observation that mature products tend to have not more than 4 levels of hierarchy in their bill of materials).

From Silicon Valley Code Camp 2010, Part II.

Day 2

In the session on Fun with HTML5, CSS3 and JavaScript, Tab Atkins Jr. [substituted for Newton Chan and] took the audience through creating a complete gaming program on the fly, called worms, by making use of the canvas element. Very educational.

In the session on REST for the rest of us, Ken Yagen provided an overview of the RESTx open source framework for creating RESTful services through demos. Key characteristics of this framework are:

1. RESTx resources are self-discoverable through RESTful APIs.
2. RESTx lets you define your services in any language of your choice.

He recommended the O'Reilly book on RESTful Web Services as good introductory reading material.

The session on Building Video Applications with YouTube API by Jarek Wilkiewicz was useful because the published APIs available both for browser-based integration with Player APIs and rich back-end data store with Data API enable rich vertical integration. Some amazing statistics:

• 2B views/day
• 150m mobile views/day
• 24 hours of video uploaded/minute

The final session of the camp that I attended was with the title Are you ready to switch your role from PM to scrum master? Do you know what you do not know? by Amit Sarkar. One thought I came away with was the Agile and Waterfall methodologies are useful in different contexts; the Agile is definitely more useful in software development arena. Has any one used the Agile methodology in, say, the construction of a large airport such as the San Francisco International in place of Waterfall methodology?

Epilogue

Pulling together all the resources to accomplish as an enormous a task as this camp is really very commendable. Thank you, Peter Kellner. Equally commendable are the corporate and institutional sponsorships that funded the activity. Particularly for the for-profit companies, this form of social responsibility will only increase societal goodwill towards them.