If you tuned into the “Building a great agile team” webinar, then you participated in a first for the Jira team: We hosted three webinars in three different time zones to try and reach as many of our customers as possible.
Between the three webinars, there were 316 questions asked by audience members. Our host Jimi Hazel and Q&A support Michael “Tokes” Tokar, chose their top 10 questions to answer in this blog (plus three bonus questions). Enjoy!
Here’s a link to watch the webinar again, or share it with your team. And learn more in the recent blog post how to form nimble agile teams.
Jimi’s top Q&As:
Q1: How do you address the classic problem of needing more development at the beginning of a sprint and more QA at the end of a sprint? Do your team members do double duty, or is work staggered (at least a day or two) to allow for testing / sign off?
A1: QA in Jira plays more of an advisory role. If the feature is a truck, they’re the “co-driver” rather than the tollbooth operator. As a result, we find this kind of staggering isn’t necessary. If you’d like to learn more about how we do QA in Jira, check out this great webinar by Penny Wyatt, leader of the Jira QA team.
Q2: Where does user feedback, user testing, user research, etc., fit into your process?
A2: The bulk of these activities is done by designers and project managers on upcoming issues, and the results are conveyed through conversations with the dev team and by attaching the relevant artifacts to the Jira issue or blogging research findings in Confluence. We developers like to sit in on the user testing and research when we can, though, because it really helps us get into the mindset of people using Jira and Jira Agile.
Q3: Any suggestions on specific processes that work with remote teams and teams in different time zones?
A3: Some practices we’ve found useful for remote and cross-time zone work are:
- Communicating primarily over Hipchat so we have a centralized and persistent record of our conversations, and so we don’t exclude remote team members
- Keeping a squad co-located if at all possible, or at least in the same time zone. In other words, dividing work along time zone lines as much as possible
- Adding team members from other time zones to our pull requests to keep them in the loop
- Finding an overlap to resolve disputes / make decisions over Hipchat video (even if it means one party has to log on for an hour or so in the late evening / early morning)
Agile webinar series: Check out our next Jira Agile webinar “Virtualized Agile.” Join us for the story of the evolution of Sonatype’s distributed agile teams as told by Mike Hansen, Senior Vice President of Engineering, and Mark Kilby, Agile Coach. In this webinar you’ll learn:
- Why distributed teams are a powerful differentiator
- How to foster a culture of collaboration within a distributed team
- Ways to overcome the pitfalls of distance in agile development
Q4: What techniques do you use for estimation of work?
A4: Our team has tried various estimation methods, including:
- Planning poker
- Writing the stories out on cards then grouping them by relative size
- Somebody calls out their estimate, and anyone else is welcome to disagree and discuss the story further
These days we generally do the third. It seems to work well for us as we’ve found our groove now and aren’t afraid to speak up if we disagree with an estimate. But it’s probably best to start out with planning poker and go from there.
Q5: How do you go about planning what items go in a sprint? Do you break down tasks first?
A5: First, some context. In our squads, we tend to keep backlog items at the “story” level (i.e. Jira parent issues). We use “epics” in Jira Agile to track larger pieces of work; they typically go for more than a couple of sprints. When considering what to put in a sprint, we try to focus on a small number of epics (the fewer the better), so all the stories in the sprint will ideally be from the same epic. Between two squads, the epics being worked on in any given sprint may overlap, but we try to avoid that. The stories will be estimated (in Story Points), and we’ll fill our sprint backlog roughly to the squad’s capacity, based on historical velocity, plus taking into account any known interruptions. Once we commit to and start the sprint, it is up to the squads to decide if they want to break down the stories further into (sub)tasks. Typically, they will do this if there’s a need to parallelize the work, or if the story is on the larger side.
Q6: How do you integrate action items from the retrospectives in the sprint planning? How are they prioritized so they don’t compete with the general sprint plan and project timings?
A6: We hold retrospectives after every sprint. With a regular cadence, we are able to distill the action items from the meeting down to 3 or less. Most of the time, these items are more administrative (for example, documenting something, setting up a meeting). We rotate the responsibilities of these items so an individual team member or squad won’t feel burdened. If an action item requires significant time investment, we’ll add it to the backlog so that it can be committed to in a sprint. We have a strong culture of process improvement, and so it’s understood that if we need to take some time away from delivering on project work in order to fine tune our process, that’s okay.
Q7: My team always has trouble with the “As a somebody ” part in the story definition. We come up with “As a company,” and “As a scrum team,” etc. Do you follow any rules around how to define that part?
A7: My first piece of advice would be, if it’s not working for you or it feels awkward, ditch it! User stories are not an integral part of being a successful agile team. We’ve experimented in different ways over the years with how to construct our backlog items. User stories can be useful, because they force you to consider the visible impact of a piece of work.
A framework we are now using heavily is based around user personas. We define realistic representations of our customers through data and research. We include these in our design activities and sometimes our backlog items, too. You can find out more by watching this talk from Atlassian Summit 2014.
Q8: What is the smallest squad size you might recommend? Is there a way to manage it in Jira Agile?
A8: A squad should be at least three people. Sick days, leave, etc., wreak havoc on a squad of two, and the size of features a two-person squad can tackle is limited. Jira doesn’t have the concept of a “team” as a first class concept, but we have found that using labels to mark an issue as belonging to a particular squad works perfectly well for dividing up the work. We also have a Hipchat room for the team, and one per squad. Our team is still small enough that everybody knows which squad everybody else is in so there isn’t a huge need to track it anywhere.
Q9: You mentioned that each squad uses separate backlogs. How is that divided from the overall product backlog?
A9: We segment the product (project) backlog into squad backlogs by using well-known labels with the Jira Labels field. This allows us to earmark certain tasks for certain squads, like bugs which came from their previous deliverables. We then use Quick Filters in Jira Agile to allow us to view each squad’s backlog individually, or issues that have not yet been assigned to a backlog.
Q10: Can you have pull request approvals trigger a transition on the boards? Similar to crucible?
A10: You sure can! We use it to transition our issues from “Awaiting Merge” to “Done,” for example. Check out this blog for more details.
Q11: Is there a suggested GIT branching methodology used by your squads that you have found particularly useful?
A11: For day-to-day development, we use the feature branching workflow. We find this provides a good isolation of work between individuals (and squads). It also works well with our continuous integration strategy: Using Bamboo, we run our entire suite of tests against each feature branch. When it comes to managing releases, the workflow starts to resemble the Gitflow Workflow.
Check out more about feature branching workflow and Gitflow workflow.
Q12: Can you set up a project (kanban board) per team in Jira Agile and then have a rolled up view of say the epic in one board, sort of like a portfolio manager?
A12: Yes. Jira Portfolio aggregates status across several teams. It is the portfolio manager of choice for Jira users. Read the announcement post to get more details.
Q13: How do you set up permissions for pull requests? Are there specific users who are allowed to approve pull requests? How can you enforce that nothing is pushed directly to master if you want anyone on the team to be able to approve pull requests?
A13: Project and branch permissions provide a flexible way to delegate access across Stash. Add a branch permission to master that only allows your gatekeepers to write to it. They’ll be able to push to master and merge PRs to master. If you’re using Hipchat, you can notify the team if anyone pushes to master directly.
You made it to the end! Watch the webinar again
Want to learn more about Jira Agile project management for scrum and kanban teams?