Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am some way through a project, on the 3rd sprint, which is about back-end processing. Let;s say the sprint name is "3. Data merging and form generation". I have 4 or 5 features in that sprint relate directly to that task, and I'm halfway though- some completed, some not, one in progress.
While in this sprint, I demonstrated some of what was happening to the client, who promptly (kind of unexpectedly) gave me a few pages of feedback purely to do with the UI. Very front-endy stuff, nothing to do with my current sprint, but still relevant and good stuff.
It seemed that at that time, it would be appropriate to drop my current back-end work and address the feedback. The reason being by addressing the UI issues, it would stop propagation of 'wrongness' to the rest of the application (Lotus Domino: That's how it works).
JIRA doens't have a facility for putting Sprints on hold, and starting a new one. You have to close a sprint.
Adding a feature to my current sprint would be fine, but would include a load of UI issues in a sprint names explicitly to do with the back-end processing.
It felt like square-peg-round-hole, and I'm not sure how this is 'supposed to' go with Agile, or JIRA.
So my question is: Is the problem that ..
Naming of Sprints shouldn't include too much commitment to their nature, so including a UI task with a sprint intended for the back-end processing woudn't be upsetting things.
If a sprint is "interrupted" like this, my notion of putting it on hold and sidetracking to another sprint isn't how Agile works (hence JIRA won't let you). Something else should happen (if so, what?)
JIRA is less flexible than Agile demands (seems very unlikely!)
Some other thing I haven't thought of.
The typical approach to scope changes mid-sprint is as follows:
If a change is relatively minor and both the team and the Product Owner agree then you go ahead make it. Typically a team will compensate for any changes, for example when they bring in a new story they would also take out a similarly sized story so that the net effect on the sprint is close to zero.
If the changes are significant the Product Owner may terminate the sprint. The team immediately starts planning for a new sprint in the same manner as usual.
It isn't all that common to name sprints with details of what the sprint contains. Just using a simple numerical sprint name (e.g. sprint 1, sprint 2) can help to make it clear the Scrum team is open to change.
In JIRA, if a sprint was terminated early I would mark it as complete and then create a new sprint. This may mess with your velocity calculation a little, but should be easy enough to compensate for.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Our Supervisor mentality is that if a bug is found in the future he wants to do this:
Find the PBI that describes the functionality that is not working correctly.
Update that PBI to current Sprint.
Create a Bug and put it under that PBI.
Create a task and put it under that Bug.
The rationale behind this is that he considers that PBI to not have correctly finished, so it has to be re-opened, and he wants the Bug to be under that PBI so that he knows what functionality was not working correctly.
I'm under the impression that the correct way really only has 2 options:
Treat Bugs at the same level as PBIs when you find them in a future iteration - create the Bug but just be as descriptive as possible so you know what functionality was the problem.
Treat the Bugs as a Task, so either create a new PBI, or copy\move the previous PBI to the current sprint, and put the Bug under that PBI, but DON'T create a task under the Bug, the Bug essentially is a task.
What would be a solution for our shop?
Actually you just need to associate the work items (PBI > Bug > Task). Once the association is created, then you can find the linked work items under Related Work.
In my opinion, both options are OK. The two options you mentioned only reflect how the work items shown on backlogs and boards. But if you already linked the related PBIs, Bugs, Tasks, then open any of the work items you can find the relationship between them (Parent/Child ~ where the bug came from).
For example:
Treat Bugs at the same level as PBIs (Bugs are managed with requirements)
Treat the Bugs as a Task (Bugs are managed with tasks)
UPDATE:
Both of them can not completely achieve your requirements (No better ways to achieve that based on the current features ).
However if you are more concerned about where the bugs come from, then option 2 ( Treat the Bugs as a Task) is better, as it can show dependencies/relationship intuitively in backlogs (Bug is under specific PBI).
If you are more concerned about the hierarchical structure of the work items, then option1 (Treat Bugs at the same level as PBIs) is better (PBI > Bug > Task).
Whatever you can find where the bug comes from via the related link.
A lot of teams I work with categorize bugs in one of two ways:
Bugs found in a sprint on items worked on in that sprint
All other bugs
For bugs found in a sprint they associate them with work item. All other bugs are treated as stand alone backlog items.
There are several reasons for this, including:
When a bug is discovered some time after the work is done it may be difficult to work out which work item it is associated with
Not all bugs neatly associate with a single work item, particularly ones not found in-sprint
Bugs found in-sprint should be immediately addressed or the work items will typically not meet the definition of done
Bugs found out of sprint need to be prioritised alongside other work items
Unless you have a specific need to associate bugs with work items (for example it is part of a billing mechanism) then any effort you put in to this could be considered to be waste. Associating bugs in-sprint with work items does not require much effort and so does not generate much waste. Doing it with out of sprint items is often quite costly in time and may be difficult to justify.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have a team of 20 people divided in 2 teams and a jira bord for both of them. We work on agile scrum methodology.
The team components are a pm/scrum master, BA, PO, testing team, ux,ui and backend dev team. The problem we have is that the bord gets messy and no one is taking care of it.
My question is who should take care of the bord to not get a mess pm, scrum master dev team?
Ideally it is the Scrum teams responsibility (everybody). The beauty of Agile lies in self driven and empowered teams. Don't try to command and control and make it habit of everyone. "Scrum master/PO" can facilitate this (help other team members to close task/US after discussion of their state see point no 2 below). If you try to hold one person responsible for it you will loose granular info and your Agile/Jira board will not reflect actual info.
"The problem we have is that the board gets messy and no one is taking
care of it."
If your team follow agile properly this situation will not occur.
Every team member update their respective task and US regularly(daily).
Use Agile ceremonies Grooming/Planning/Demo(acceptance of US) for Clean up task. Discuss with team [merge duplicates/Priorities and delete obsolete one.
one of the Agile principle is Limit work in progress:One should not keep more than 1 US/task in in-progress. Should complete one and and move on. Or else if he is blocked then only pick next one.
4.At end of sprint/Iteration Conclude US's state Accepted/Completed/Carryover/removed/Moved to backlog.
We usually take it(Clean up) as a retrospective action item and make sure stewardship followed in next sprint not only with respect to code but JIRA as well.
"Re-iterating: you can request PO or scrum master to facilitate/watch
it. but better to ask your team member to take this responsibility. or
Story owner should make sure his/her user story [JIRA in your case]
reach to a conclusive state and cleaned up in JIRA."
We update & clean the board at the Daily Scrum. This makes sense as everyone is telling what they completed yesterday. After the Scrum board is updated we start planning the day.
In this case the Scrum Master should teach the Scrum team to self-organize and keep the Scrum board up-to-date.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I have the following question.
Often in our project issues stay in progress forever.
To resolve this we would like to introduce a new workflow where if a JIRA issue has been idle for 2 weeks it will automatically have its status set to Postponed.
How can this be implemented in JIRA? I checked the column constraints on the board, but there is no constraint related to time.
I think you don't have to build a workflow to mask your problem with regards to the "Issues which stay in progress forever", but you need to fix it.
Fixing it means you need to coach the team and support them with various technics to avoid "never ending stories". I would suggest to:
Implement DOR (Definition of Ready) - avoid picking up issues which are not yet investigated, groomed and not enough clear to pick up. In our case the story could be added into the sprint just after all external dependencies are sorted out. Use the INVEST model which says INDEPENDENT How can you commit to deliver issues where you depend on any external team?
Slice big stories - There are plenty of technics how to split large user stories. In general its a bad practice to add a story into the sprint if the estimate shows that it can't be completed. Ideally the right size of the story is "that you have 2,5 story to each dev in single sprint". This doesn't mean that every dev should work on his own story and they can't collaborate, but it means that for e.g. 4 devs for a single sprint 8-10 stories are ideal. (Easier testing, collaboration, better planning, more stable velocity, etc etc..)
WIP (Kanban limit work in progress) - Putting the 'flow' back in workflow with WIP limits - Atlassian This is something which is easily configurable in Jira.
Show the 'DAYS IN COLUMN' indicator on cards - This shows a series of dots on each card (up to the width of the card or a maximum of 32), representing the number of days that the issue has been in the column. This could be a useful info for the scrum master to see whether there is any impediment which should be sorted out
Don't use blocked or postponed status. This is just my personal advice. Statuses like blocked/postponed could generate a habit that the issues will be really just postponed instead of removing the impediment and blocker. It is always easier to flag something as blocked as removing the impediment. Its your scrum masters responsibility to remove the obstacles and eliminate the waste.
Backlog grooming - Groom the backlog periodically and if you have problems with the external dependencies flag them in advance. Seek for external dependencies by purpose and identify them as soon as possible. This will give the SM/PO hopefully enough time to deal with them before the issue will be added into the sprint and picked up by the dev team.
Why an issue is sitting idle for two weeks? Is it because of external dependencies or issue is too big to complete in two weeks?
I am not sure about the Jira work flow and if Jira can move it to postponed state. But you can move it back to backlog at the end of the sprint.
But if it happens because the issue is too large to fit in two weeks, then I would recommend to slice it into smaller tasks to fit in sprint.
I hope it helps.
If we ignore the arguments how good a workflow and its management is raised by #shippi the solution to this question is explained here.
https://community.atlassian.com/t5/Marketplace-Apps-questions/ScriptRunner-how-to-change-status-of-an-Issue/qaq-p/628842
Shortly said Jira has ability to execute scripts , they can also be scheduled and executed on regular basis. What needs to be done is a script to be written and scheduled that every day checks how long an issue has been idle and set the appropriate status.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Using the Agile Scrum methodology, stories that are ready from the backlog can be moved into a sprint
There is generally a process to agree when a story has been sufficiently refined to be considered ready
How do you indicate this in Jira?
My backup plan is to just have an undated sprint named "Ready", and then move ready stories from the backlog to "Ready" to a dated sprint, but that seems messy
A common approach is to use backlog refinement sessions to decide which stories are 'ready'.
For example, you could have a backlog refinement session planned several days before the end of a sprint. In that session the Product Owner would present the stories they would like to target for the next sprint. The team reviews the stories and points out any potential problems with adding them to the next sprint. At that point the Product Owner could mark stories as 'ready' if they found that useful. Other stories might require a bit more preparation work and the Product Owner has the days until planning to do this in.
I've seen a couple of approaches to recording the 'ready' state. One is to have a 'ready' column in Jira. Another possible approach is to use a radio button style custom field called 'ready'. That would allow you to add in a quick filter to the backlog view in Jira agile that would give you the ability to only show stories that are ready at the planning session.
I think the process of agreeing wether or not a story is 'ready', is sprint planning.
Sprint planning gives developers the opportunity to dig into the story, and ask questions from the product owner, and decide it's readiness. If the product owner isn't able to make the story clear during planning, then it's not ready. The acid test for readiness though, in my opinion, is wether or not developers are comfortable giving an estimate to the story.
Reflecting this status in jira is another matter. In the past I edited the Jira workflow, and added additional state 'ready to estimate', but I've since removed it, it didn't add much value but increased complexity.
I think you should be aiming for the majority of stories that make it into sprint planning to be clearly defined and ready to estimate, but it's fine if there are a few there which aren't, so long as the planning session doesn't turn into a 'design the feature' session. Someone needs to call the fact that it's not ready, and toss it from planning.
Tim
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are in the process of starting to use Scrum (in combination with TFS 2010 and the MS Scrum template) in our company. Since none of us have any experience there are still some questions to be answered.
Since our Product Manager and Scrum Master are non-technical people it would mean that we, the Developers will be part of the meetings that split up the feature requests in small Product Backlog Items. It is my belief that we can do this on our "planning poker" meetings to discuss the feature. But how is this planned in? Let's say that we get a new feature request in the middle of our sprint. (Our sprint will be 80/20 timed.) Should we keep this also into account when planning our sprint, or would it simply mean that the time we spend in that meeting must result in items moved back onto the Product Backlog.
We know we should split a feature up into as many PBIs as we can (and of course, that makes sense) and that a single PBI should not exceed the length of one sprint. That also makes sense. But where should we draw the line? For example, our application communicates with several USB devices. The feature request is that we should communicate with a new device. Implementing this is a 2 part job:
a) add the communication with the device to our USB library;
b) add UI support for this device
Should we split this up into two separate PBIs, or is this one PBI of which we should create multiple tasks?
On a side-note: when a PBI has been added, should we create a task for each PBI when we start implementing it? As far as I see in TFS we cannot set remaining work hours on a PBI. So my initial idea was to create a task for each PBI. But I know some colleagues will find it "a lot of work" to create a task for a PBI that only has one task. How should we handle this?
In Scrum, it is the PO's responsibility to break the features into small-enough user stories. That being said, there's nothing wrong with the PO getting help from the team (or anyone else for that matter) in splitting them. The planning poker session might be a good place to fine-tune the split, due to the team's input on the complexity of each story, but the PO should have a sense of how to split the stories beforehand.
The planning session should take roughly half a day. Definitely not a significant portion of each sprint. Regardless though, the remaining hours in the sprint (e.g. 90-5=85, in a two week sprint) should be the amount of time that the team has to fill with the stories' tasks. Of course, no matter how much time is left in the sprint, any stories that the team can't commit to should be returned to the product backlog; they won't be done in this sprint.
The stories should be sized appropriately, i.e. can be completed in a single sprint. Personally, I prefer to size stories so that a few stories can be completed by the team in one sprint. A good rule of thumb (but not a hard rule, by any means) is to stop splitting your stories when you reach the point that they can be released by the team in 3-5 days.
Though you didn't ask how to split your features and split them along the lines of Core capability, entry barriers, key differentiators, and nice-to-haves.
Regarding Breaking the stories into tasks: You should have at least one task per story. Stories define what needs to be done; Tasks define how. You should probably have at least one task per participating component of the system, as well as one task per actionable item in your definition of **done. If you have only one task, then you probably don't have a definition of done, or your stories are defining implementation, rather than functionality.
With regard to TFS - TFS doesn't change any of the above, though it does support everything I suggested.
Yes, it's better if you create tasks under PBI even if its only one task, because the PBI was made to monitor product progress, it used story points in estimation (Relative Size), but the task is used to monitor work progress, it used hours in estimation, so every work items have different purpose.
1) The time taken to split the stories out will be reflected in your team's velocity so you shouldn't really have to do anything to plan it in. If you are spending say, half of your sprint in story planning/splitting and getting 5 stories done per iteration, then your plans will reflect that. Through the use of retrospectives you can see that spending less time in story splitting will increase your velocity to say, 8 stories per iteration. Keep an eye out for side effects of spending less time splitting stories though so you can see both sides of the coin.
2) Not knowing the application, I would say that one way of splitting this out would be
Alert User When New USB Device Is Inserted (This would show potentially a default icon)
Alert User When iPhone is attached (This has more specifics around the device, and potentially a different icon/image)
Alert User When Android is attached (Ditto above)
Alert User... (Potentially one for each of the supported devices)
Definitely try to avoid splitting across technical lines such as "Front end" and "Back End". It feels right at first due to our technical nature, but demos don't really have the same impact and your PO and Scrum Master won't really have as good of a measure of progress.
3) Task creation is something that your team needs to figure out. If you're running 2 week iterations and the team is not finding task breakdown useful, then I'd say don't do it. If the team feels as if it helps them break down the work necessary to create the story then, by all means, do it. Task creation for the sake of task creation doesn't make a whole lot of sense IMO.
Hope that helps!
Brandon