New answers tagged jira
0
There are a few things to think about here.
Firstly, how do you define your priorities? If they are only defined at the individual team level then it makes prioritising requests from other teams challenging.
Ideally where work is shared there needs to be a clear, top-level prioritisation in place so that is easy for teams to know what they should be ...
0
The question to ask yourself is:
What information do we want to get from a burndown?
Different teams will use the burndown in different ways.
A popular approach is to burndown on completed stories. This gives an indication to the team if they are 'back-loading' the sprint, i.e. that stories only get done towards the end of the sprint instead of ...
1
Work is Done or Not-Done
Scrum does not require the use of user stories, story points, or burn-down charts. They are commonly used as a best practice, but it's important to understand that they aren't framework requirements.
With that said, widely-accepted agile frameworks generally treat work as either done or not-done. Product and Sprint Backlog Items ...
3
What is the definition of work done in Scrum
Work that satisfies the Definition of Done, which is defined by the Team.
The problem with this is that work being closed on a daily basis is not shown on the Burndown chart
This is the correct behaviour. From Scrum's perspective, an incomplete story provides zero value, so the burndown shows zero progress.
...
2
JIRA allows you to modify your workflow and add new statuses. You don't need to divide columns, just add new columns that reflect what you want.
I would look to build a workflow something like this:
To Do
Dev
Dev Done
Test
Done
Thus a tester would look at the "Dev Done" column for work that they can pull into "Test".
If you have ...
1
In Jira, the default columns on a Kanban board are Backlog, Selected for Development (To Do), In Progress, and Done.
For each column, depending on the workflow you're using, you have different status.
If your board's project is using the Jira default workflow:
To Do - Open, Reopened
In Progress - In Progress
Done - Resolved, Closed
You can change ...
1
Personally, I think you do need to spend time and decompose your tasks. Looking at your examples, if you don't decompose, you'll end up with tickets that remain in progress for much longer than you prefer.
As a good example, let's look at Subtask 2
Implement the search function
You have presented this as if it has already been decomposed from the ...
1
I would advise against a sub-task approach as it is often painful for Devs to have to update each sub-task with their progress.
Your first subtask sounds like it is more appropriate as a Spike.
Subtask 2-4 sound like they could be acceptance criteria in a single story
Subtask 5 could be a task item or a subtask (either on is fine)
A driving principle ...
1
It depends on what you are trying to visualise.
Kanban is about optimising a workflow and visualisation is an important part of this. If your sub-tasks represent stages of a workflow then it may make sense to represent them as columns.
If, however, your sub-tasks are very fine-grained then this could result in a Kanban board with a large number of columns....
Top 50 recent answers are included
