Building any multitiered solution is not just creating a User Interface to render the data, there is most likely a service tier that fetches data from a database, and serves that data up to the UI to then be rendered. How do you derive work items in your product backlog? One User Story, and multiple child tasks, one task per tech stack tier, UI, service tier, and database? Or three user stories, one per tech stack tier?
User Stories Defined, Per Tech Stack Tier
There are clear advantages of representing most work items with User Stories such as deriving story points, determining team average velocity, and a more accurate burndown chart depicting a downward trending scope and implementation of user stories.
Using child Tasks of user stories may obfuscate the total work required to implementation of the solution unless baked into the parent story points. Tasks are typically tracked in terms of hours, and separately user story points are calculated/derived from a collective, relative effort estimation, e.g. Fibonacci sequence; 1,3,5,8,13,20…, and many teams may overlay this scale to fit their sprint duration.
Feature and Story Planning – At a Glance
In order to organize each feature, and correlated user stories, teams may use a prefix in the title of the user stories, such as [UI] or [DB]. At a glance, a product owner, or the implementation team can see if all the required stories for a given feature have all the elements required to implement the feature. For example, if a new report needs to be created, multiple stories must contain [UI], [API], and [DB] stories.
Drawbacks – Accepting a User Story as Complete
If you segment your product backlog user stories based on tech stack, you may need to wait until all related stories, UI, API, and DB have been implemented. For example, If your API and DB stories are developed, and not the User Interface (UI), you’re QA/Testing may not start until the UI story has been deployed. Of course, your tester could test the API using testing tools like SoapUI.
One of the first hurdles to get over when working with a manager who is accustomed to working with Waterfall projects:
Show me our milestones for this project, and when are theses project artifacts to be delivered? Is there a timeline that articulates our deliverables? I want to know when I should get engaged in the project, such as when milestone delivery dates’ slip, and we need to revisit or rebaseline our projected delivery timetable.
Going through the agile transformation on the team level, invoking the Agile Values empowers the team to “Respond to Change”, which may deviate from our initially targeted “milestones”. Not only the timetable may shift, but the milestone, and what it represents may significantly change, and that’s OK with an Agile team. Product stakeholders outside the team may not be adaptive to changes in deliverables. “Outside” stakeholders may not be engaged in the cadence of Scrum ceremonies.
When working with Agile toolsets like JIRA, and Azure DevOps, a Gantt chart does not traditionally come to mind. We think of a product backlog and user story commitments to the current, and next sprint(s). Maybe we are targeting several sprints of work transparency, such as leveraged with SAFe, and Planning (IP) Iteration. We’re still not seeing the visuals in the “traditional” style from Waterfall efforts.
Azure DevOps Provides the Necessary Visuals
So, how do we keep our “outside” product Stakeholders engaged in the product life cycle without inviting them to all Scrum ceremonies? We don’t have Gantt charts, but we do have “Feature timeline and Epic Roadmap” as a plugin to Azure DevOps through the Microsoft Marketplace, for FREE by Microsoft DevLabs. To me, this functionality should be “out of the box”, but apparently this was not the case. I had to have the need/pain in order for me to do research to find this plugin and install it in our enterprise environment. Why would Microsoft disassociate itself with this plugin to some small degree? I can only hypothesize, like the man in the grassy knoll. Regardless of why, “It’s in there, ready for you to install
Articulate Epics, Features, and User Stories
1. Populate the Product Backlog with Features and Epics
Using Azure DevOps, during the initial phase of the effort, Sprint 0, work with your Product Owner to catalog the Features you are looking to deliver within your product evolution, i.e. Project. Each of these features should roll up into Epics, also commonly called Themes. Epics are the highest level of articulation of delivery.
2. Define User Stories, and Attribute them to Features
Working with the Product Owner, and the implementation team, create User Stories in the Product backlog which will help the team to implement the Feature set. Make sure to correlate each of the User Stories to the Features defined in your Product Backlog. User Story, effort estimations would also be helpful to determine “how big”, i.e. how many sprints it will take to implement the feature.
3. Plan Feature Delivery Within / Across Sprints
Within Azure DevOps, Boards –> Backlogs, Team Backlog, and select “Feature Timeline”. From there, you are able to drop, drag, and define the periods of Feature delivery.
All Sprints are displayed as Columns horizontally across the top of the chart. There is an indicator of the current sprint.
On the left side are Epics, and the rows REPRESENT Features within the Epics.
Select the box, “Plan Features”, and a column of unplanned Features will appear to the right of the screen.
Drop and Drag a Feature from the list of unplanned Features into one of the defined Sprints. Deselect “Plan Features”, and then select the “Info” icon on the planned Feature. A Feature dialog box will appear to the user with all of the User Stories associated with the Feature.
User can drop and drag User Stories from the “Backlog” column to any of the Sprint buckets.
Finally, the user should define the Start Iteration and End Iteration for each feature, showing how Features span multiple sprints and an estimation of when the Feature work will conclude.
Note, although Features may span multiple sprints, User Stories cannot within this Feature planning view of Azure DevOps. The approach of a single user story fitting into a single sprint makes sense as implemented in the “Agile Mindset”.
The Final Product – Epic and Feature Roadmap
Although this view is immensely valuable to articulate to ALL stakeholders at both a high and low-level, Epic, Feature to the User Story, there is no Print capability, just as annoying as trying to print out Gantt charts.
Microsoft 365 Project offers the capability of building Roadmaps and Timeline (Gantt) views. From Microsoft Project 365, the user connects to the Azure DevOps server in order to import all of the User Stories desired to track. At first glance, the user would be tracking Azure DevOps, User Stories, which, in my opinion, should be done at the Feature level, one layer of abstraction for business communication.