Talk:Scrum (management)
From Wikipedia, the free encyclopedia
| This article is related to Wikipedia:WikiProject Method engineering. | |
 |
Please note that the use of Wikipedia to host this project has been questioned. Please read this discussion and, if you wish, contribute your thoughts there. |
What is a living backlog? Is it just a master list of things to do which is updated regularily. If yes, what is special about this? Hasn't this been used all the time? --Hirzel 21:49 10 Jul 2003 (UTC)
It's nothing revolutionary, no. There are two backlogs, for the Sprint and Product. The Sprint backlog is the todo list of the current monthly iteration, and the Product backlog a list of everything anyone has requested.
Developers should update the Sprint backlog daily, with an estimate of how much work is remaining on each of their tasks. This is maybe what is meant by "living" - you always have an idea how much work is left to do, and as the backlog is essential to the scrum process, you can be sure it's going to be up to date.
Anyone (really, anyone) can add requests to the Product backlog. As such, it is the one place that captures all ideas about the product/project. Even stuff that might not be possible now - "I want a man on Mars!" can be added. Once a month, the business owner (product owner in scrum parlance) puts the list in order or priority to the business. Again, the fact that anyone can add to it, at any time and anyone can see it and the current priorities at any time make it a key document, and the focus of a lot of attention.
If you have a short term todo list (sprint backlog) and a long term todo list (product backlog), and review it frequently/daily with everyone involved in the project and are constantly keeping it up to date, and use these 2 documents as the central point to capture ALL requests, then you more or less have a backlog. Murray 20 Jan 2004
[edit] Removed a chunk of unsubstantiated, unencyclopaedic content
The following chunk was in the article, unreferenced, and with a very "how-to" feel to it. I've put it here in case someone can pull something useful out of it. -Kieran 10:29, 25 October 2005 (UTC)
Begin chunk:
In the recent times most of the managers have recognized the value of the people centric management practices against the process centric practices. In an environment of the constantly changing requirements & stakeholders, it is not logical to control the project on the process level. In simple terms "a rigid process cannot help in adopting to the customer's needs".
For the Software projects its is very meaningful to combine the SCRUM with Extreme Programming and Test-driven development. This helps to have a systematic and disciplined practices with respect to the management, code, and testing practices.
End chunk
[edit] Removed link to the word "deliver": why?
I removed the link to the word deliver because it links to page that defines the word in the traditional sense (e.g. trucks and warehouses) while the word is used on this page in the software sense of "completion". It didn't seem helpful to me to link from here to that page. Dave Menconi
[edit] Comment on simplified scrum description
Under "simplified Scrum" it says
* Schedule a demo of the software with the customer/client a month from now
This sounds a lot like the horrible practice of picking dates out of thin air and then whipping the team to meet the date (I could tell you such stories...). It's not clear from this discussion how the scrum version would differ.
On the other hand, this is just an example of a way to implement a lite version of scrum and it might complicate this overmuch to explain how you pick the date.
Still if *I* had this reaction maybe others would too; if so Scrum would be painted with a negative reaction because of an example.
Dave Menconi
[edit] Adaptive Project Management Comments
The paragraph at the top of this section is not crystal clear. It has a lot of good information but it's like a bunch of ideas are all jostling to be presented.
The rest of the section was good, imho
Dave Menconi
[edit] Please say more about the significance of 1 month
In two places it's mentioned that things are done monthly (here in the dicussion when explaining about backlogs and in the simplified scrum). Are sprints usually month long? Or is monthly just an example of a "short period of time".
This is kind of significant because having monthly deliverables (if indeed that's one of the features) would be one of the most obvious and significant difference between scrum and other more traditional software development methodologies (the other big one, I think, is the daily meeting). Many of the features look, at first glance the same -- for example, I've always done software iteratively(in 3-18 month iterations) and we always have a list of tasks (controlled by the leader) and so on -- but take on a different tone when the time scale of things is taken into account.
Stephiee01 19:42, 16 August 2006 (UTC) Sprints/interations ideally should not be more that 1 month in duration without reconvening with stakeholders and product sponsors to review the sprint accomplishments in the event that changes should be made, or priorities have changed. With longer iterations, teams typically loose focus of their sprint deliverables, and the "pressure" to get the job done is eased quite a bit. In other instances, there is the concept of mini-sprints, which are shorter interations, usually a week to 2 weeks in duration. Also, typical 30 sprints can be broken down into "mini sprints" with weekly/semi goals to reach the end of sprint goals identified at during sprint planning.
Please keep in mind that following scrum to the letter does not determine success. Rather, scrum is a practice that should be altered to fit your best business practices and own processes and procedures. Scrum should be used as a framework and adapted within current successful practices. As more project are developed using the scrum methodology, you will begin to see what aspect(s) fit and which ones don't, and you can begin to build around the key principles of scrum.
[edit] Merge with Scrum (development)
Is there a difference between Scrum Development and Scrum Management. It seems that these two articles should be merged.
- I agree. There is a lot of overlap between these two entries. Winterstein 10:29, 19 July 2006 (UTC)
- Agree. A lot of info to merge together though - possibly merge the pertinent bits of (management) into (development) and then move the latter into the former - (development) certainly seems more well set out. --Firien ยง 12:16, 10 August 2006 (UTC)
- I too Agree. Scrum Management and Scrum Development are processes of the Scrum Methodology. Its nearly impossible to peform one process without the other. They work hand-in-hand to the overarching Methodology...Scrum. Stephiee01 19:22, 16 August 2006 (UTC)
- I do not agree with this proposal. Although Scrum is very much driven by the development team, the management of Scrum is a global perspective of the project requirements and the iterative components. Applying the two different categories to Scrum would help define these perspectives. I do think though that the definition and goals for management and development need to be more clearly defined. Maxwellvz 13:29, 25 September 2006 (UTC)
- Agree. Scrum messaging is unclear as it is, no need to confuse it even further.
- I disagree. Scrum development is a different process than project management. The different PM tasks should be compared in the project managemnt section. If someone does not understand the processes, then they need to get some real experience. Can you say Beck?
- I agree: Scrum is described by Ken Schwaber (in 'Agile Software Development with Scrum') as something wrapping developmental practices which preexist or which are designed specifically for the project. It does not focus on the developmental practices at all - only mentions which practices could be good to use when you set yourself the goal to deliver something working every month. On the other hand, the management aspects are taking gantt charts or similar and reformat them into a backlog ('cutting through complexity'). Scrum is the glue between development and management, in my eyes, and should not be split into the management and the development aspect. That, indeed, would revert the biggest benefit of Scrum.84.75.128.192
- I agree. Scrum is an approach to software development, so it is product-oriented. It is not meant to be a project management methodology. Eric
- I agree. Concerns about keeping the two Scrum sections in Wikipedia. It is a method of managing a project and details can be given by updating this area. Perhaps the sections when merged should just be called SCRUM and not Scrum (Development).
- I don't agree. Agile Scrum can be used for any project with deliverables, and it should be separate. Jcposey 01:54, 17 February 2007 (UTC)
- What other non-software development kinds of projects use SCRUB? I can't see a construction or oil-drilling project use SCRUB, so I wonder what other domains do? [Michael]71.202.149.150 06:49, 26 February 2007 (UTC)
- I'm using it right now in a software implementation - it's an entirely different field. Dibbler5 11:30, 26 March 2007 (UTC)
- I think both articles should be merged, but under the title of Scrum (methodology), as opposed to either Scrum (development) or Scrum (management). There is a certain amount that is common to both methods, and this should be highlighted. Other project management methodologies have begun life in the software development world and moved to other fields. (I'm particularly thinking of PRINCE2 here.) Dibbler5 11:30, 26 March 2007 (UTC)
[edit] Advantages and Disadvantages
This article practically tells us the advantages of SCRUM. Wouldn't it be nice to have some disadvantages of SCRUM listed or at least some negative opinions of SCRUM? SCRUM can't be all good right?
