Tagged: agile

JIRA story point totals using Ruby and Rest

I’m using a hosted version of JIRA and needed to obtain quick totals based on filters that I have setup.

I could not find any easy documentation online so I thought I’d share my quick hack.

The REST API is very well documented and uses the same JQL as the filters do.

In order to view the commit list for an iteration I have some JQL that looks like:

fixversion = 20120611 and fixversion was 20120611 ON "2012/06/11" AND status NOT IN (canceled, "on hold")

In order to feed that into the API I needed to construct a url along the lines of

https://energyplus.atlassian.net/rest/api/2/search?jql=#{urlencoded JQL string}&fields=customfield_10003&maxresults=400

The &fields=customfield_10003 instruct the API to return a minimal fieldlist and only include that custom field, which for me is Story Points.  By default the API will return 50, so bump that to 400 to be safe.

The Ruby code looks like

def getData(api,qs="")
 url = "https://energyplus.atlassian.net/rest/api/2/#{api}?#{qs}"
 res = open(url,
                "Authorization" => "Basic " + 
                  Base64.strict_encode64(USERNAME:PASSWORD)) {|f|

Calling that function I use something along the lines of

result =  getData("search", "jql=" + URI::encode(jql + '&fields=customfield_10003&maxResults=400'))

The final step is to loop through all the results and sum the ‘Story Point’ values

puts "Total: " + res["issues"].inject(0){|sum, item| sum + item["fields"]["customfield_10003"]}.to_s

If you are having issues with the SSL cert, try adding


Here is my actual script in its undocumented glory: https://gist.github.com/2919437

If you think you can improve it, drop me a note – I’m hiring 😉

the measure of Awesome

Development at work has been trending well in the new year and the team is getting excited about our formal incorporation of practices such as TDD and pair programming.

I’m definitely perceive an intangible benefit in culture and fun. With a full test suite and engaged developers working out loud coding is fun again.

I give a lot of thought to developer efficiency and generating metrics around our output is very important to me.  We are at a point in this iteration where I have too many stories in progress and it is taking a few extra days to get work completed and accepted.  This does not concern me greatly since this is a new team and it usually takes a few turns to get into a rhythm.  I was walking down the hall and one of developers said that things are going ‘Awesome’.  I said “Great, but awesome is not a metric“.

Since then he and the rest of the team have risen to the challenge and we have some demonstrable facts in low bug counts and high numbers of actual hours (hands on keyboard time) logged.

I’ll have a clue in a few weeks and ‘know’ in a few iterations that TDD and pair programming have raised productivity in this team.  For right now I do think things have improved and I feel that our velocity is going to increase.  IMHO my personal job satisfaction has increased.

So I may have been nieve last week in saying awesome is not a metric.  I’m now thinking that awesome must a metic with a correlation to both employee retention and code quality.  We simply have not developed the tools to measure and understand this thing we call ‘awesome’.  I can only observe the secondary effects that occur when there is “awesome” within a team.

This is kind of like gravity.  Science can only measure the effects of gravity but you can’t run without it.  And running beats floating back and forth aimlessly any day…..