by Jeffry Hesse, Michael Prescott and Chris Wilper
User Stories have become fairly common in Agile Software Development, so much so that they are baked into most of the modern toolsets like JIRA, Rally, etc. Teams get together, create User Stories and collaborate in real time.
Sonatype’s Nexus team is not unlike other Agile teams, however: we don’t work face to face. The Nexus team that I support is fully distributed with great minds from Europe, UK, Canada and the United States all working together to create Nexus.
This introduces fun challenges when you try and wholesale apply the ideas of a framework such as Scrum, particularly around Sprint Planning and writing stories as a team in Backlog Refinement. So how do we take a Story from a Raw Idea to a Ready User Story?
Backlog Refinement in the context of Sonatype is when we as a team get together to find stories with very little detail and add the sufficient amount. We end when we feel as a team that we understand what we are trying to accomplish.
Given our geographic challenges, we started doing Backlog Refinement multiple times a week at varied times. We have a time that is better for our European colleagues and East Coast of America/Canada, and a time that is better for the West Coast America/Canada members. This gives us a decent Venn Diagram overlap of “mind power”. Of note, we have other members that participate on Nexus, but I’ve narrowed down the Venn Diagram to show our fully dedicated Development team.
Our Backlog Refinement meetings function in a way in which we identify the Topic we want to dive into ahead of time. For that topic, say it is “NuGet Hosted Repositories”, we identify a Captain. This Captain captures their notes on the subject, and then we dive into Refining a story.
Tools for Backlog Refinement
Some tools we use to run our Backlog Refinement meetings are:
HipChat is used for capturing asynch conversation that a member may not want to stop conversation with, VOIP for synchronous conversation, and Join.Me to show our screen so we can write together. We use the Captain’s Notes to lead either how we craft a User Story, or how we break it down into Tasks. But wait, I just said Tasks? Why?
Sprint Planning – Part 2, How Do We Do This?
Scrum in it’s most strict implementation would have you get your entire team together to break down Stories/PBIs into Tasks. Unfortunately, due to geography we don’t have much time to work with and we’ve used our valuable overlap time to allow important team conversations around code to occur. So to move forward on breaking down future work what we as a team do is consistently identify Captains of Functionality, and that Captain pairs up with a Co-Pilot and other team members to break down Stories into Tasks.
How does this look?
Say that we have a User Story about NuGet Proxy Repositories in Nexus 3.0 (we do, for the record). The Acceptance Criteria that the Captain and others have worked to create is:
- Implement handlers for the various read-only NuGet gallery protocol endpoints (ODATA queries, downloading, etc.).
- Implement the caching of remotely-fetched components in component storage.
- If a user requests a package we don’t have by URL we should send a request to fetch the metadata from the remote proxy
- Feed counts should reflect what the upstream repo reports
- Search results will be slightly different due to the algorithms we use versus NuGet.org
- If the remote repo goes down, a user should be able to still use the proxy repo with locally available metadata and packages
- Locally cached NuGet packages should be visible in Nexus ElasticSearch results
- Nexus Admins will be able to configure the cache duration/size for queries to remote repos so that we don’t overload the remote repo
- If a user Searches on the NuGet Feed search results are capped at 40 entries
- Supported clients are Visual Studio 2013’s package manager, the VS package manager powershell utility, the standalone Nuget.exe command-line client, and the Nuget Package Manager.
The Captain, Co-Pilot and the other team members met at a convenient time after Sprint Planning and broke this story down together. In the case of the NuGet Proxy Repo this was Michael as the Captain, Chris as the Co Pilot, Stuart and Tamas as interested parties. They went through the Acceptance Criteria, and created Tasks for “How” they want to address the Acceptance Criteria, while keeping the Tasks bounded by the reality of “User Functionality”, meaning we don’t create tasks that say “Implement Database” as this is a tad ambiguous and it’s hard to tell when it’s Done.
How would a Nexus User for example know when we finished implementing a database? We instead create a task that says “Implement Metadata Caching Proxy Endpoints”, since it is much easier to understand when you are Done in that case. For example, a Developer using Nexus could hit our new Proxy Endpoints and start to get information. Obviously if our deliverable was a database, we’d task around that a bit differently but the former was worth explaining. For this Task, we created the following detail:
Implement the NuGet protocol so that the following endpoints will work:
- Static files required by the protocol
- Feed operations
- find packages by ID
- Individual entry
- $count versions of each of the feed operations
Queries from clients should be passed on to the remote repo verbatim, and the resulting metadata parsed and cached locally. Queries should then be re-run against the locally cached metadata. Searches should be capped at 40 entries.
Test the endpoints in the four supported clients.
This task detail is not meant to be 100% picture perfect, but more so to establish a plan to move forward on how we want to implement the Acceptance Criteria. It’s also to expose that plan to the whole team for some good constructive criticism, so that the rest of the team that wasn’t present can still offer up their thoughts and opinions.
We created many more tasks to ultimately accomplish the Acceptance Criteria, and then we broke to start work on these items. How do we work together as a team? I’m glad you asked, we’ll answer that in a separate post on how we as a fully distributed Agile team have been pair programming and using other collaboration techniques. I’ll also go into explaining the Co-Pilot role a bit more, as that is becoming valuable in our Agile workflow.
Latest posts by Jeffry Hesse (see all)
- Upgrade Nexus Repository Manager 2 to 3: Get Early Access - August 15, 2016
- Tame The Ruby Colored Snake: Python + RubyGems + Repository Manager OSS Early Access - July 28, 2016
- Spring Into The Future: Nexus Repository Manager 3.0 Release - April 6, 2016
- Ground Control To Nexus Users: Nexus Repository Manager 3 Milestone 7 Release - January 21, 2016
- What’s up Doc(ker): Nexus Repository Manager v3 Milestone 6 Release - November 11, 2015