I have been a Certified Scrum Master for about 6 years now. In my experience I have had the opportunity to learn and grow and effectively manage (from a CSM level) the needs of an average software development team. I have recently been assigned to a 5 man team with a 6th member (Product Owner) who is building their backlog with little or no information to go off of. Most of the issues (user stories/tasks) being written are written with the intent to go and find more information on something. They are not written in the standard "As a Customer I want ________ etc."
The team is made up of contractors who are supporting a government organization. The organization is not using Agile. Almost everyone on the team is familiar with Agile and they would like to use it, however, the work that they are doing is not fitting into that mold.
To make a long story short they WANT TO be able to size their stories, plan effectively for the next sprint, and see more realistic metrics when they use reporting tools like their burndown charts. Unfortunately - they are not developing anything. There is no end product to be provided to the customer. They are pretty much lifting one thing and shifting it to another.
Best example I can give without leaking sensitive data is that the organization has a house and the house has stuff in it but they want a new house - no one knows how much stuff is already in house A (the original house) so no one knows how much space will be needed in house B (the new house that needs to be built) no one knows how many rooms or floors or other needs common for a house that they are looking at. So most of the work they have been doing is "discovery". Going to house A and scoping it all out, taking notes, and disusing game plans for the work ahead. So how the heck do you use JIRA or apply Agile anything to a project like this?
Thanks in advance!!!
Hi Crystal - This article is a good place to start: Applying Agile to non-Software projects.
In brief: Recognize that all teams are organized to produce something of value to the organization. Whether it's software, marketing material, movies, etc. Agile is a methodology to help teams plan and execute in a way that delivers value early and often in a manner that can respond well to changes in circumstance throughout the process of delivering value.
If you can decompose the work to be done into small enough units of work that one can make steadily more reliable effort estimates of and deliver in a time frame that demonstrates progress at a steady cadence then you are doing basic Agile no matter what you are doing or delivering.
Consider also the nature of the team's work. If it is a continuous stream of work that is fairly consistent in nature and effort then consider Kanban. Not all Agile is Scrum. Agile is all about regularly planning, executing, and reflecting so that the team continues to innovate and improve the way they deliver value to the organization. Both Scrum and Kanban can accomplish this. Which one you choose depends more on the nature of the work and the structure of the organization.
We also have an Agile team that has to do a lot of Discovery work (no BA on the team).
What we do is create a Spike for the exploratory work with specific Acceptance criteria that includes questions to be answered, and full documentation of future work based on the findings, written in Gherkin, either for the team to start working or possibly assigned to a different team. Depending on the complexity of the work, the team can point it and start to build velocity. This way you can also still get to "done" and track burndown over time. The challenge is you may be adding more than you are working, but that half the fun.
@Michael Kuhl (Bob Swift Atlassian Apps) indicated, this doesn't have to be a Scrum framework. Kanban may be a better fit, as it allows the PO to continuously prioritize the backlog. Jira is a great tool for both setups and you can customize a workflow that meets your team's needs and their definition of ready and done.
For us, a Spike is just on the Story, but we name it Spike: to differentiate it from development or admin work. We have also added a few custom fields (namely, Story to capture the use case and Acceptance Criteria for the questions and expected outputs) . This way, we can query and report on these independently, vs trying to find specific text from the Description field.
I'm attaching a screenshot of one of our tickets so it may make more sense.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events