Tag Archives: User Stories

Agile, Development, SDLC, Software Development, Technology

Azure DevOps “Out of the Box” – Getting Started with Customizations

December 27, 2022 Ian Roseman Leave a comment

New to Azure DevOps? Here are a few customization recommendations you can make with minimal experience and deliver maximum value. User Stories are an essential part of delivering using agile methodologies, and Azure DevOps provides a basic template for creating a User Story, such as title, description, and acceptance criteria. However, there are a few additional fields the author of user stories can capture to maximize their agile journey such as MoSCoW priority, Precedence, and Size Estimate to name a few.

In addition, there is a Marketplace (i.e. Library) of Azure DevOps Extensions that can enhance your user’s DevOps experience. The post will cover the recommended extensions to apply to “Out of the Box” implementations of Azure DevOps.

Azure DevOps “Process” Updates: New Fields

Adding Fields to a User Story is very simple, as long as you have access to do so. Upon opening your Azure DevOps (ADO) project, select “Project Settings”, and the “Project details” page should appear. Select the “Process” defined for that project, e.g. “Scrum”. Depending upon which Process type selected, “Scrum” or “Agile”, you will see “Product Backlog Item” or “User Story”. Both may be used interchangabily. Note that only “inherited” processes can be modified by “Project Collection Administrators” group.

A list of Work Item Types appear. Select “User Story” or “Product Backlog Item”. The Layout of the work item will be displayed. Now you are able to add fields, by selecting the “New Field” button.

User Story – MoSCoW for MVP

For a Minimum Viable Product (MVP), where is the line drawn to get the product “out the door”? Here is a methodology called MoSCoW, self-explanatory, in which the capitalization is important and stands for:

“Must Have” – we aren’t going to production without it
Should Have” – borderline must have but could fall off the MVP list if there is pressure to reduce scope to meet timelines, for example.
Could Have” – a story identified but not prioritized in the currently targeted MVP.
“Won’t Have” – identified and then forgotten. It will never reach prod.

User Story – Precedence (Prioritization)

Reminiscent of the original BASIC programming language, using 10, 20, 30, etc., line numbers for execution sequence. In addition, like in BASIC, implement precedence by 10s, so there is room later on to fit in additional work items.

Priority within the Sprint for a given team member

How should someone on the implementation team prioritize their work? Especially important if the team runs out of time for a sprint and only produces the highest business or technology value first.

Priority within a Sprint for all team members

Collectively, as input from the product owner or team tech lead, the most important work items to deliver within a sprint.

User Story: Size Estimate (paired with Story Points)

Relative, standard, effort estimations are essential that everyone on the implementation team is “on the same page.” to sizing the user stories. Although “Story Points” is “Out of the Box” for User Stories, a “Size Estimate” field is not. Relative effort estimations I’ve used before are Tee Shirt sizes (X-small, small, medium, large, X-large), and can be correlated to Story Points to attempt to quantify the effort in days.

User Story: Lead Developer

A custom “Lead Developer” field is valuable for quickly identifying who performed the work. The current “Assigned To” person may not be the developer who implemented the User Story. Most likely, it’s a QA tester or the Product Owner for Accepting Stories.

This could be helpful if you want to track each developer’s progress either by the SUM of Story Points or the COUNT of Stories.

Risks to Compliment Issues

If you’re tracking “Issues,” an “Out of the Box” Azure DevOps work item, then why not add a custom object in the “Process” section called “Risk” and any fields you would like to track with that custom RIsk object?

Azure DevOps Extensions

Analytics

Created by Microsoft, this extension may or may not already be rolled into the core Azure DevOps product. It’s ideal if you want to externalize in-depth reporting using Microsoft Power BI.

Open in Excel

Created by Microsoft DevLabs, this extension may or may not already be rolled into the core Azure DevOps product.

Azure DevOps Office® Integration 2019

The best tool for importing and exporting work items from Azure DevOps to and from MS Excel. It can be downloaded here.

Delivery Plans

Created by Microsoft, this extension may or may not already be rolled into the core Azure DevOps product. It’s the closest I’ve seen (for free) with a graphic depiction of delivery timeframes in a Gantt-like chart. You can’t print or export it, which is a massive inhibitor to sharing your timelines with stakeholders outside the ADO universe.

Estimate

Created by Microsoft DevLabs, this extension may or may not already be rolled into the core Azure DevOps product. It’s Planning Poker in Azure Boards. I enjoy Planning Poker, but this integration may be more convenient because it can save the Story Point values directly to the User Stories. Also, note some corporate environments BLOCK “Planning Poker” on the firewall due to the words in the URL.

Feature timeline and Epic Roadmap

This Azure DevOps extension by Microsoft DevLabs is a close 2nd to the “Delivery Plans” visualization of deliverables. Again, no export or print capabilities.

Retrospectives

This extension is a “Must Have” for all teams leveraging the Scrum Retrospectives session. This extension, built by Microsoft DevLabs, is highly configurable and is ideal for remote teams unable to perform this activity in person.

Agile, Development, Project Management, SDLC, Software Development, Technology

Delineation of Work Items, Segregated by Tech Stack

April 15, 2021 Ian Roseman Leave a comment

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.

Agile, Business, Project Management, Reviews, SDLC, Software Development, Technology, Work

Best Kept Secret of Azure DevOps by Microsoft – Feature and Epic Roadmap

June 27, 2020 Ian Roseman 4 Comments

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.

Feature Timeline - Plan Features Step 0 — Feature Timeline – Plan Features Step 0

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.

Feature Planning - Feature, User Story, Sprint Planning — Feature Planning – Feature, User Story, Sprint Planning

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

Drawback

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.

Alternatives

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.

The other aspect of MS 365 Project, is the cost, three tiers, and if you want to use the Roadmap capability, it’s $30 per user/month. Here’s a video blog, 4-minute video that shows how to get started.

Agile, Development, Technology

Microsoft’s Azure DevOps – Planning Poker Estimation Tool

January 4, 2019 Ian Roseman 6 Comments

Although I’ve been a huge fan of PlanningPoker.com since 2011, my Scrum Product team consisted of more than five members, and their Free Membership allows up to 5 users. The team I was working with had just started their agile transformation and was trying out aspects of Agile / Scrum they wanted to adopt. They weren’t about to make the investment in Planning Poker for estimations quite yet, so I stumbled across an estimation tool as a free add-on to Azure DevOps.

Microsoft’s Azure DevOps solution is both a code and requirements repository in one. Requirements are managed from an Agile perspective, through a Product Backlog of user stories. The user story backlog item type contains a field called “Story Points”, or sometimes configured as “Effort”.

Ground Rules – 50k Overview

All team members select from a predetermined relative effort scale, such as Tee Shirt Sizes (XS, S, M, L, XL) or Fibonacci sequence (0, 1/2, 1, 2, 3, 5, 8, 13, 21, 34…) All selections of team members are hidden until the facilitator decides to expose/flip all team selections at once. Flipping at once should help to remove natural biases, such as selecting the same value as the team tech lead’s selection. After that, there’s a team discussion to normalize the value into an agreed selection, such as the average value.

Integration with Azure DevOps

The interesting thing about this estimation tool is you can explicitly select stories to perform the effort estimation process right from the backlog, and in turn, once the team agrees upon a value, it can be committed to the User Story in the Backlog. No jumping between user stories, updating and saving field values. All performed from the effort estimation tool.

Roseman Solutions LLC