Thursday, October 31, 2013

Scrum Tools: Jira Agile (formerly Greenhopper)




The next few posts are going to talk about different tools that you can use to manage the Scrum process. There are quite a few out there, but I"ll start with the one I'm currently using, Jira Agile. It was formerly known as Greenhopper and is part of the Jira family of the Atlassian bug tracking and project management products.  Many Open Source projects use Atlassian tools to manage development so lots of people are familiar with Jira, for better or worse.

I've taken a liking to it, but it may be that I've not had much to compare it to. Prior to adopting Scrum/Agile my company used Bugzilla for bug tracking and that was it, but we needed a tool to help manage Scrum online since our team has many remote members. Many teams find that a large white board with post-it notes and an Excel spreadsheet for the product backlog works great; we needed a virtual whiteboard instead of a physical one.

We now use Jira Agile for bug tracking as well as the Scrum management process, as all new issues are now managed as part of the product backlog.  Now that I've been using the tool for a while, I'm efficient in inputing the data, updating items, and such.  It took a while to get the hang of where everything was located, but now I can easily update our estimates and move stories around when we are in the middle of our sprint planning meeting.

From a cost perspective, price is pretty reasonable and you can opt for a cloud-hosted site or create a local installation.

Things I like about Jira Agile:

  • The Work view of the Agile Scrum Board is a really useful way to visualize the status of your stories. It shows all the stories in the current sprint, who they are assigned to, and in what stage they are in. This view is shown in the picture above. You can customize the workflow and have different lanes as needed for your process. We happen to use To Do, In Progress, In Testing, In Review, and Done.  I bring this up during every daily Scrum meeting and use it to refer to when team members are discussing their status.
  • The Plan view of the Agile Scrum Board lets you easily reorder the product backlog and move stories into different sprints.  It can get a little clunky dragging when your backlog gets big, but  overall this feature is very useful.
  • You can do original estimates in story points, then track time in hours once stories have been moved to sprints.  Velocity can then be expressed in story points for stories completed.  You can also do original estimates in hours and calculate velocity that way if you so desire.
  • The Report view of the Agile Scrum Board automatically calculates sprint burndown and velocity charts for you throughout the sprint.  Other areas of the system allow you to calculate release burndowns for stories assigned to a particular release version.

Things I dislike about Jira Agile:

  • In the Plan view of the Agile Scrum Board you can sort Epics by priority in the left hand pane, but you can't view the priority order of these Epics in any other way that I can figure out. I can search for and get a report of all Epics, but cannot seem to sort them in the priority order shown here.
  • Email notifications aren't very good.  Email notifications are configured to be sent whenever certain activities take place, like when a story moves from In Progress to In Testing. However, this can cause a lot of clutter because Jira sends one email for each piece of data that is changed.  I think that Jira should bundle up changes and send a summary only of changes done say in a 5 minute window. Typically when you update a story you might update the hours worked, add a comment, and change status.  You'd like to get just one email instead of 3.
  • There was some pain around getting everyone to have an easy to use view of their currently assigned sprint stories.  Our solution was to use the Work view and create filters to show only stories assigned to you, or stories that you are assigned or are watching.
I've gotten into a groove using the tool and I can say that I would recommend it, especially if you need to track bugs for an existing system.  In the next few posts I am going to reevaluate some other Scrum and Agile tools to see how they measure up.

What tools do you prefer for Agile and Scrum?


Monday, October 28, 2013

Bundling Bugs

Sometimes you end up with a lot of bugs in your product backlog.  This can be difficult to manage, especially if you already have a large amount of backlog items.  I recently attended a scrum master certification class and asked about this issue.  One suggestion for dealing with this is to create a single backlog item that bundles more than one bug for a particular component together into one backlog item. Bundling smaller, related bugs together (as long as they can be finished in a sprint) allows you to manage the bugs from the product backlog without unnecessary clutter.  It doesn't solve the problem of having too many bugs in the first place, but it can hep you to manage them more effectively.

How does your team manage bugs in the product backlog?

Wednesday, October 23, 2013

Would Scrum Have Saved HealthCare.gov?



This NPR story, It's Easy To Blame The Canadians For HealthCare.gov Problems, talks about the federal government's rules for dividing up large contracts amongst many contractors and how that may have contributed to the issues with the HealthCare.gov website.  It contrasts the situation with the more trouble-free website from the state of Colorado's health insurance market's site.  Colorado built its system with what appears to be an Agile process, rolling out the portal in stages and realizing that some advanced features would not make the original release date but core features would be completed.  Could Washington streamline it's contract process to allow large projects to be done using an Agile process like Scrum, or does its heavier bureaucracy make it impossible?  Obama has recently put a new manager in charge; I hope we get a peek at what he does to solve these issues.

Saturday, October 19, 2013

Where Did Scrum Come From?



http://www.aericon.com/wp-content/uploads/2007/10/windowslivewriterscrumwebdevelopment20-a179image05.png

Seems like you can't talk about software development without someone bringing up Scrum and Agile these days.  Ever wonder where it all started?  

Jeff Sutherland created the first Scrum team in 1993 and modeled the new software development process on a 1986 Harvard Business Review article called "The New New Product Development Game", written by Hirotaka Takeuchi and Ikujiro Nonaka. Takeuchi and Nonaka are highly regarded business school professors and researchers who have studied leadership and management in top companies in Japan and elsewhere. Their observations became the root of Scrum, which Sutherland then adapted to software development.  

You can read more about this history of scrum on Sutherland's blog:Takeuchi and Nonaka: The Roots of Scrum

Sunday, October 13, 2013

Planning Poker Estimation with Remote Teams


Even though Agile software development favors co-located teams, sometimes getting everyone together all in one place is just not possible. If you have team members that work remotely all or some of the time, or are working with different company divisions or outside consultants and need to do estimation during release planning it can be difficult if you want to play Planning Poker.  This blog entry from fourkitchens.com describes a clever way to use Google Docs to help remote team members vote. It's a great idea that doesn't take a lot of time to set up and can allow this particular estimation process to run more smoothly when people can't all be in the same room.

On Scrum: Playing Planning Poker with a Scattered Team

Wednesday, October 9, 2013

What's the best day to start a sprint?

When do you start and end sprints at your organization? Do you always start and end on the same day, or does it fluctuate? My teams currently end sprints on a Friday and start them on the following Monday, and that has worked well for us.

We typically do sprint demos on Thursday afternoons, disuse the sprint progress with stakeholders on Friday, officially end the sprint that day and then start sprint planning on Monday.  There can be problems with people being off for long weekends or holidays, but in general that's not been too much of a problem, and by doing the demos on Thursday afternoons that helps a bit.  We realize that the demos might not have all the features in place, but we try and reserve Fridays for lower priority bug fixes or loose ends to tie up to finish off the sprint.  A weekend break is also nice as a Scrum Master or Product Owner/Manager, because you can use the weekend to react to stakeholder priorities as needed. 

Most importantly, what do the teams think?  Let them have a significant say in when your sprints start and end.

Other teams have found that starting in the middle works better for them. These links pose that a mid-week start can be helpful:


What's your best practice?