Dilemma: Small business, rapidly developing, probably using Jira inefficiently...Help
I would like to detail our current dev-process and I will footnote each section with how we use Jira. We have been using Jira for about 6 months now and I need to start streamlining it and making it work for us more efficiently, but am out of ideas.
1). Specification designed and passed to our developers [Jira blank tasks created for each new funtion required and left unassigned for any of the dev team to pick up and complete]
2). Task is "Picked up" by a developer [Assigned to a developer, who marks off his/her progress manually in percentage at the end of every day.]
3). Task Completed [Developer will "Resolve" the task and leave a comment if needed, this will then be re-assigned to "Checked-In". All "Checked-In" tasks sit waiting to be updated to the lates build of the overall solution on our test server]
4). Server Updated [Tasks sat on checked-in for each specific project are bulk updated to a status of "QA"]
5). Our QA operative tests each task individually [Any issues found mean the task is "Re-opened" and assigned back to the developer who comittedt he work. Relevant comments added. Any new bugs are raised as seperate tasks]
6). Tested & Complete [If tasks are succesfully tested they will be marked with a status of "Tested" by our QA team, then patched live to our current live version once stable/tested]
At the moment, our main issue can be described as "Throwing rice granules into a fan and trying to catch them all on the way back out". We have limited QA resource so there is a bottleneck and tasks hover around4/5 (as above) for a long time. I think we can simplify or fortify our use of Jira in a few ways. Our current downfall is the reporting aspect, we have no reports set up and the only notifications we have are the standard ones sent when tasks are picked-up/completed etc.
I was looking at Greenhopper (Jira Agile) as this would help us very much, but we are far from an Agile development cycle.
It would be useful to know how others have used Jia in their organisations, as although we may know our software within our business I think we have run out of ideas in terms of Jira management and development of our lifecycle using this technology (We run the risk of getting "set in our ways"). I have heard that some businesses add the initial task to Jira with User-stories and develop around that? That would be worth finding our more about. Also, perhaps using a header task for the functionality and sub-tasks for the breakdown of each bit of work required?
Your help ideas no matter how constructive would be very beneficial.
If any further info is needed, please ask and i will gladly provide it.
Green hopper will make it easier to view things. But your main problem is process. Without a strong change control and engineering process, unplanned work getting picked up will always be a problem.
If you guys go with agile workflow, there are 2 popular flavors of Agile I think work well.
Scrum - work is picked up in fixed time period "sprints", during planning meetings at the beginning of each sprint, where a certain number of story points (preestimated work) are adopted and commited to. So for example, say the team picks up 5 stories they know they can complete, and stick to it for the sprint (most use 2 weeks)
Kanban - work is organized in a continuous queue by priority, and there is a fixed number of buckets. And each bucket only allows a certain amount of WIP (work in progress). In order to take on more work in any bucket, the bucket downstream needs to have slack to take on that work. So say you have a WIP of 3, that would mean You can only have 3 stories under development, 3 under testing, and 3 ready to deploy. In order to say to take a new story under development, you'll need to finish the 3 under testing to make more room in the bucket.
I think Kanban works well for early stages when you care about velocity. I prefer Scrum when dealing with cross team dependencies.
Thanks for the info David.
I have been looking into implementation of Agile processes for a while now and (im not going to lie) I am having difficulty thinking of how to and the implications of implementing it. I have read many books and case-studies, which all hint at the long term gains opposed to minor short-term struggles.
There is one thing I am unsure of with the Scrum process though. How are the time-blocks implemented if the nature of the work required is not completely known. For example, as per most software houses we will develop a new feature and discuss/spec it beforehand. Within the process we will stumble onto a game-changer/blocker. These blockers could range from change in technologies to change in requirements (Unfortunalte we support 5 web applications which can interconnect, across 3 different versions, across all browser platforms including our own)..... So my question is, within the scrum process, how is the time-block (due-by) changed? Will we have to drop weight on the feature being committed by sacrificing some functionality? I would assume the due-buy's are always met?
Thanks again for your reply, my current workplace are set in their ways and would rather struggle through and think hard of ways to solve things rather than ask other experienced professionals for their opinions and their advice. Really appreciate forums like this.
Originally Posted by ColBurg
Common way to do estimate is scrum is Planning Poker, Planning Poker: An Agile Estimating and Planning Technique. Stories are at a high level estimated in terms of story points relative to each other in terms of complexity. So the idea is if a story is too big, it gets broken down into something that can be accomplished with a deployable outcome by the end of the sprint. The main difference between traditional RUP is you have a prioritized backlog of things to be done for each team, instead of a master gantt chart of sub projects. It's still the Product Manager's job coordinate, but instead of strict timelines, he just prioritizes what you do first. When the risks or size of a story is unknown, usually a spike for prototyping and research is done to learn more.
Some people start bothering shortcuts and a few works for them which isn't anything bad,I somehow feel that it has to be that much sensible i mean the kind of outcome is necessary that needs to be correct and at the same time good at working. agile and scrum methodologies So putting your stuff to a shortcut way is actually something that works for it.
Well said and is very true.