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 6 years ago.
Improve this question
Agile Scrum methodology does not use reports.
Do you agree with this statement?
Can Product Backlog, Sprint Backlog or Sprint Burn Down Charts be considered as reports?
The Scrum framework was designed from the start to be transparent.
There are three critical components to this:
A public task board (showing work in progress)
Sprint reviews (showing achieved progress and open to all stakeholders)A public product backlog (showing future work)
It is also worth noting that the Product Owner is the person most interested in this information as they own the product. They are involved every day with the team and so have a deep understanding of what is going on.
The issues that occur in Scrum reporting tend to happen due to flaws in the way the Scrum framework has been implemented. For example, if not all interested stakeholders are attending the sprint reviews then there can be misunderstandings. Also, if the Scrum Team is not allowed to be self-organising then there may be some concerns over communication with the technical managers.
Having said that, many teams use reports to supplement the Scrum transparency.
The two most common reports are:
A sprint summary (typically done by the Scrum Master)
A product update from the Product Owner
Mike Cohn talks about the sprint summary here.
Product updates have many formats. The most successful ones I have seen are clear and consise summaries of work in progress and planned work that are targetted at people of all levels of technical knowledge (including business users that are non-technical). I have worked with Product Owners that write visually attractive product updates that effectively market the Scrum Team to those that do not regularly attend sprint reviews.
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 4 years ago.
Improve this question
I am new to Scrum and I am trying to use it for website support and maintenance.
For website support and maintenance, we often receive small tasks, for example: replace a banner on homepage, change phone number on contact page, remove image xyz on article 123, etc... I don't know how to deal with these small tasks in Scrum.
At the moment, I create a single task in backlog, and a single Sprint for each task. Then, execute each task individually. Am I right?
In Scrum we have fixed length, repeating sprints. We bring work to the sprint, rather than creating sprints from tasks.
This is useful for a number of reasons, including:
After a while we get to know the capacity of a sprint.
We know at the start of the sprint what we will be doing and there is no change to the sprint goal during the sprint. This stability helps the team get organised.
The regular cadence helps the team get into a rhythm of planning, executing and then adapting.
Scrum isn't as effective if:
You don't have a team of 3-9 people
Work items and priorities change frequently and stable sprints are not possible
From your description, I wonder if Scrum is the best agile framework for your team.
Perhaps you might consider using Kanban?
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
What are advantages and disadvantages of Scrum over Kanban methodology.
Which one is better for mobile development?
TL;DR; You don't have an Apples to Apples comparison here.
Scrum is am empirical framework optimised for delivering Software
Kanban is an empirical method of optimising any existing process
Kanban
Kanban needs way more discipline in your team and organisation to be able to get value. You start by modelling your current processed and then make small incremental changes to the process to optimise it for your needs. Most teams fail to optimise effectively and end up where they started (or close to it) forever.
Kanban is not focused on Software Delivery and is best suited to tasks that have a relatively small standard deviation in size of batches. This allows you to monitor flow and optimise for it.
Scrum
Scrum is a Framework that enshrines accountability, inspection and adaption, and transparency as its fundamental pillars. The three clear roles provide accountability so everyone knows what they have to do. Each and every one of the Events provides a Kaizan moment to allow you to change. Every one of the Artefacts creates transparency so we all know what is going on.
The most important artefact is the Increment of Working Software because that is what out goal is. You can read the Scrum Guide to find out how it all goes together.
Scrum is focused only on Software Delivery (although modified versions like EduScrum exist) and is best suited for tasks that have a large standard deviation in batch sizes.
Conclusion
There is no 'better' option, its what works for you. I see more teams succeed quicker using Scrum than Kanban.
If you bought the board game monopoly would you expect it to come with a rule book or a strategy guide? Right, a rule book. Will the rules help you win? No, you will need to come up with, and experiment with, strategies that work for you.
The Scrum Guide is the rule book for Scrum
In Kanban you come up with your own rule book as you go along
All the practices common to either technique are complimentary.
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 have a number of doubts associated with Agile methodology. I'm assuming the sprint span is of 2 weeks.
If tester gets a number of defects in the first half of second week which are of high priority, what should the developer do if there is a
good amount of stories remaining untouched?
What should the developer do if his work doesn't complete within 2 weeks time?
What should the scrum master do, if the there is unfinished work?
What should the team do if the tester finds some defects of the previous sprints?
I have found these kind of questions from some interview questions list.
Could anyone please explain me more on this.
Q1.
It is considered a good practice to prioritise completing work over starting new work. So, in your example, it would make sense for the developer to focus on fixing defects rather than starting new stories.
Remember, the goal of a sprint is to complete valuable work, not to have lots of work in progress.
Q2.
If the team feels they won't complete the work they planned in the sprint then they should let the Product Owner know. This helps to set the expectations of the Product Owner and gives them an opportunity to re-prioritise based on the new information.
Failure to complete work in a sprint is usually a result of either taking too much work in to the sprint or something unexpected impacting on the team during the sprint. Neither of these are a disaster, but a team may wish to bring them up in their retrospective to see if there are any lessons to be learned.
Q3.
If there is unfinished work in a sprint then it does not contribute towards the velocity calculation for the team. Usually this means the velocity goes down and so the Scrum Master would encourage the team to bring less work in to future sprints.
Q4.
If the tester finds defects from previous sprints then they should be raised with the Product Owner and added to the backlog. If the Product Owner regards fixing the defects as a priority they may suggest bringing them into the current sprint. It would be up to the team to decide if this is appropriate and they may wish to remove some existing planned work to compensate for the added scope.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Is there a methodology where the process combines Scrum and Kanban and has both fixed sprint schedules and project backlog? I've heard of Scrumban and Kanplan but I'm not sure which is which.
Thanks.
Kanban is a method to visualize and improve whatever you do currently. The Kanban Method encourages you to visualize your current process on a Kanban board, establish a pull mechanism to ensure team members take up new work when that actually have capacity, and improve the flow of work thru your process.
If you are currently doing Scrum and you apply Kanban on top of it to improve your team's performance, you are doing what is popularly called Scrumban.
Kanban helps Scrum teams identify and resolve bottlenecks in their current processes, using concepts such as WIP limits (to reduce multitasking) and classes of Service to deal with the variations in demand (the different types of work a software team usually does, such as new features, break-fixes, etc.) and make commitments to their product owners and other stakeholders based on their real capacity to deliver work.
In this process, Scrum teams may often move towards a 'sprint-less' delivery (just do releases on a regular cadence), while improving the frequency with which they deliver quality software. If they do so, many teams call that thenKanban process. However, that is not a necessary step at all. Team's can simply continue with Scrumban.
If you'd like to learn more about this, you can read up here - http://www.digite.com/Kanban-guide/what-is-scrumban
Hope this helps!
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
When using an agile methodology on a team programming project, what should be done when several people needs to work in something that is to be used by everyone. For example, There is a User entity, and two people have to do requirements that need to use that entity. So, first an skeleton is created and then the activities are assigned? or what is the procedure in these cases.
And second, Is it possible to find information that addresses this kind of issues that can occur when applying such methodologies?
Thanks
The best thing about Scrum, is that it is an amazing tool for identifying bad practices. This is one of the cases. An agile team should be working with as many hands as possible, on the same requirement (requirement, feature, user story - same thing). The division of work between members should be based on the tasks needed to complete the requirement, no the requirements themselves.
Each task would be defined based on the modifications that need to be made to a certain component. Doing that will not only make the problem go away (nobody's working on the same code), but will unite the team members' efforts, and make them function as a real team, rather than a disparate group of individuals that happen to share a room and a manager.
As for official information on the subject, I can suggest reading any book about Scrum, but you might want to focus on the following sites:
Introduction to Scrum
Mike Cohn's Blog
Scrum.org
A few great books:
Succeeding with Scrum - Mike Cohn
Free ebook - Scrum & XP from the Trenches - Henrik Kniberg
And finally, if you pardon the shameless plug, you can check out my blog - I have a few posts on this subject (such as this one) and others from my experience about implementing agile methods in software teams.