Tag Archives: Azure DevOps

Delineation of Work Items, Segregated by Tech Stack

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.

Azure DevOps 6 “Most Wanted” Features

Integration of SharePoint into Azure DevOps and Toss the Current Wiki

JIRA and Confluence a powerful combination. Microsoft should ditch the Wiki integrated into the Overview module, and use SharePoint (lite) instead. Put your best foot forward!

Backlog “Feature Timeline” Filtering

As I’ve mentioned in prior posts, the add on “Feature Timeline” by Microsoft is a fantastic bridge between Agile and Waterfall, displaying a Feature [i.e. Milestone] timeline. Expand upon this module with additional capabilities, such as filtering Features by Tags.

Microsoft Teams Chat mentions in Azure DevOps (ADO) Product Activity Feeds

I like trolling the Activity Feed on my Dashboard as much as the next person. Let’s add some external, yet related data sources, such as Microsoft Team Chats directly correlated ADO Team == Microsoft Team. Is that a setting, linking MS Azure DevOps Team to Microsoft Team? Should be…

Auto-generation of Release Notes After Each Build from Repos into the Azure DevOps Wiki

  • Similar to Java Doc, in line code comments roll up into C# Function doc
  • Commits Required to Specify Correlated Work Item IDs
  • Dynamic Wiki Page creation for each build, including release notes, unit test suite execution results

Ability to Create Azure DevOps Wiki pages from within Power Automate (i.e. MS Flow)

Shared Queries Segregated by Teams within the Project

Teams each have their own view of relevant Team information such as Dashboards per team

Runner Up Features

  1. Need the ability to re-name Azure DevOps Dashboards
  2. Need the ability to Clone Dashboards
  3. Product / Project / Portfolio Level Capacity Planning – 3rd party integration, OnePlan handles this requirement

Agile Manifesto – Personal Reflection

Individuals and Interactions over Process and Tools

Stereotypical software developers are introverts, heads down, coding. Articulating where they are in the development lifecycle sometimes heavily relies upon tools for measuring progress such as JIRA, Product Backlog status of User Stories, e.g. “In Progress” with an Effort estimation of 3.

“Blocked” User Stories may require the implementation team to “break out of their shell” and work with their teammates to “unblock” Product Backlog items. It breaks people out of their comfort zone. We need to discuss options and opportunities for removing blockers. “All for One, and One for all”

Working Product over Comprehensive Documentation

Over a decade or so ago, the measure of my merit was the complete test coverage of requirements for software implementation. Back then I was a QA lead, and my focus was to make sure all use cases for the software under development had complete test coverage.

Requirements changes from our business through our business analysts must be vetted with the QA team so use cases/test cases must be updated to ensure coverage. Sometimes a dependency of one requirement had a ripple effect throughout the software, so lots of documentation updates were required. Milestone dates were in many cases fixed, so teams were squeezed to do more with less time.

Flash forward to today, and leveraging Agile principles, I breathe a slight sigh of relief. Iterating product delivery via sprints every 2 weeks is supremely better than attempting to traverse updates to Business Requirements Documents (BRD), and technical specs. User Stories in a Backlog are much more succinct, and in some cases, a bit more abstract leaving functionality open to some level of ambiguity and interpretation.

Sprint Close scrum ceremonies every two weeks with our Product Owner, the central mouthpiece for the definition of the software product helps define the path forward. Did we get it right? Where do we need to make changes? There is no substitute for an evolving product and accompanying dialog with our Product Owner.

Customer Collaboration over Contract Negotiation

Both sides of the aisle seem to agree, building a solution with iterative input from the customer enables the product vision to be realized far better than without frequent touchpoints.

Statements of Work (SoW) to engage 3rd party solutions integrators (SI) may be abstract in some way. Holding vendors accountable for loosely formed requirements is tenuous at best. Quibbling about he said, she said is a waste of time.

Fail fast, engage regularly and often with our [Business] Product Owner enables us to collaborate on a working solution. The focus is on the evolving product vision and not the paper trail.

Responding to Change over Following a Plan

A “last-minute” change request? It could push back our timelines and accompanying milestones. Dates can’t change, and teams need to absorb the changes, i.e. nights and weekends. Responding to incremental changes at a regular cadence is a sustainable life cycle.