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 Advisor Plugin for #Microsoft Teams is able to observe team interactions, such as conference calls within Microsoft Teams. The Advisor can derive “dialog intents” and provide recommendations for improvement. A retrospective on communications, such as Scrum ceremonies
Voice Recognition During Teams Meetings
Technology that leverages voice recognition, such as Interactive voice response (IVR) solutions are fraught with failed recognition. IVRs are used to answer calls in just about every company, which prompts for either a phrase from the user on what they want and the ability to enter a numeric value correlating to the desired intent. Challenge #1.
Dialog and Intent Identification
Beyond trying to identify the user’s intent from a phrase or sentence, a dialog, a series of interactions between two or more team members is even more complex. Current AI models that identify intent from a sentence or phrase have a mixed variable of accuracy, which is why these models must be tuned over time. A collective of interactions, a dialog between two or more team members, has a much higher level of complexity to identify intents. Challenge #2. Once a dialog intent(s) has an “N”% level of accuracy, rules may be fired with any number of outcomes, such as unintrusive logging of Agile suggestions for best practices, and next steps: e.g. a retrospective of the scrum ceremony.
Dynamically Identify Roles in Teams Meetings
Who participates in Microsoft Teams meetings and team chats can be associated with Microsoft Teams’ member profiles, such as Scrum Master, and Product Owners.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Dialog Intent Rules for Agile Guidance
From the above agile principles, we can derive the following dialog intents and precise recommendations for improvement.
Barriers to Implementation
At the current level of Artificial Intelligence (AI) Digital Assistants, i.e. chatbots, even the “best in breed”, has “difficulty”, i.e. lower probability with intent recognition, with a single sentence or phrase. Multiply that by interpreting an interactive dialog with multiple sentences, multiple participants, and exchange of responses, feasibility is highly speculative.
And Still More Opportunity: Recognition of Facial Emotional Expressions
Expressions of people may be able to be determined, and opportunities for suggestive posture can be advised. Even body posture folded arms as an example, can imply a guarded opinion, and not open to compromise.
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
Need the ability to re-name Azure DevOps Dashboards
Need the ability to Clone Dashboards
Product / Project / Portfolio Level Capacity Planning – 3rd party integration, OnePlan handles this requirement
The bartering of effort estimations between a team of 5 or more is really cool to witness and even further awesome to negotiate the consensus process. Not quite the process of the US Congress, but still attempting those on the periphery, extreme right or left of the bell curve of outliers to move toward the consensus. Discuss and draw near the point of consensus under which individuals discover their own need for resolution under grounds of somewhat tangible to their position of an item so complex gives one hope for a grander purpose.
A synonymous flip of the cards leading to the reveal moment is humbling when a team, after several rounds of dissonance, start into a pattern yielding the voting of a collective cohesion. Why do we start voting along a mutual agreement without the need for cohesion?
Can I Convince You to..
What if Chris Wallace facilitated a Planning Poker exercise between the two presidential candidates instead of a debate, driving consensus between the two presidential hopefuls?
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.
Outside the Product Owner and the implementation team, senior stakeholders may require milestones articulating deliverables.
Epics or Themes, high-level declaration of the “Release” essence, rolls up from Features, and Product Backlog Items (PBI). Relative effort estimations may be applied at the PBI level, and then rolled up to calculate/guestimate the duration of Epics.
Look toward SAFe (Scaled Agile Framework) to change the culture by providing an opportunity for the entire organization to participate in the Agile process. “Product Increments” present windows of opportunity every 8 to 10 weeks.
Product Increments may involve multiple scrum teams, their scope, and how these teams may intersect. In order to synchronize these Scrum Teams, SAFe introduces Agile Release Trains (ART), and Release Train Engineers (RTE) to coordinate cadence of the scrum teams to be in alignment with Epic and Feature deliverables.
Stakeholders may require a “waterfall” plan to understand delivery timeframes for milestone artifact deliverables. For example, “When do we deliver in the plan? We have dependencies on XYZ to build upon and integrate”
External teams may have dependencies on artifacts delivered in the plan thus cross scrum team interaction is critical, sometimes through a reoccurring ceremony “Scrum of Scrums“.
Additional transparency into the scrum team or the “Circle of Trust” can be provided through the use of Dashboards. Dashboards may contain widgets that produce real-time views into the current initiative. Key Project Indicators (KPIs), metrics being monitored to determine the success of Product ABC Epic Phase completion.
Dashboards may include: Average Team Velocity, Burn Down, Burn Up, Bug Status by Severity, and metrics that are initiative focused, e.g. N out of Y BI Reports have been completed.
I can’t help but chuckle at this scene with Peter Quill and the rest of “the scrum team” as they “deep dive” on the plan. It sounds more like the waterfall approach, the stakeholder and Project Charter on a napkin.
Product Owner knowing a relatively small portion of “the plan” before executing the plan. Fail Fast, and Fail Often.
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.