Search Results

Search found 397 results on 16 pages for 'scrum'.

Page 8/16 | < Previous Page | 4 5 6 7 8 9 10 11 12 13 14 15  | Next Page >

  • How to make sprint planning fun

    - by Jacob Spire
    Not only are our sprint planning meetings not fun, they're downright dreadful. The meetings are tedious, and boring, and take forever (a day, but it feels like a lot longer). The developers complain about it, and dread upcoming plannings. Our routine is pretty standard (user story inserted into sprint backlog by priority story is taken apart to tasks tasks are estimated in hours repeat), and I can't figure out what we're doing wrong. How can we make the meetings more enjoyable? ... Some more details, in response to requests for more information: Why are the backlog items not inserted and prioritized before sprint kickoff? User stories are indeed prioritized; we have no idea how long they'll take until we break them down into tasks! From the (excellent) answers here, I see that maybe we shouldn't estimate tasks at all, only the user stories. The reason we estimate tasks (and not stories) is because we've been getting story-estimates terribly wrong -- but I guess that's the subject for an altogether different question. Why are developers complaining? Meetings are long. Meetings are monotonous. Story after story, task after task, struggling (yes, struggling) to estimate how long it will take and what it involves. Estimating tasks makes user-story-estimation seem pointless. The longer the meeting, the less focus in the room. The less focused colleagues are, the longer the meeting takes. A recursive hate-spiral develops. We've considered splitting the meeting into two days in order to keep people focused, but the developers wouldn't hear of it. One day of planning is bad enough; now we'll have two?! Part of our problem is that we go into very small detail (in order to get more accurate estimations). But when we estimate roughly, we go way off the mark! To sum up the question: What are we doing wrong? What additional ways are there to make the meeting generally more enjoyable?

    Read the article

  • Should the number of developers be considered when estimating a task?

    - by Ludwig Magnusson
    I am pretty inexperienced with working in agile projects but I have tried it a few times and I always run into this problem when estimating a task. Do we bring into the estimate the number of developers that will work on the task? Let me explain: Task A is estimated to one time unit and developer 1 will work on it. Task B is also estimated to one time unit and developer 2 and 3 will work on it together. I.e. if developer 1 begins to work on task A at the same time developer 2 and 3 begins to work on task B they will all finish at the same time according to the estimate. Should the estimate for task B be twice of that for task A or the same? The problem as I see it is that when a task is received and estimated, it is not always possible to know how many people will work on it. And if you assumed that two developers would work on the task for one time unit but it turns out that only one developer will actually do it, this will not automatically mean that that developer will work on it for two time units. Is there any standard practice for this?

    Read the article

  • Agile Tools For Handling Multiple Projects

    - by f1dave
    Currently I'm leading our agile team in an iteration manager role as well as doing my regular dev work. One of the difficulties I'm facing as an IM is tracking burn-down/burn-up; not because I can't produce graphs, but because there's multiple projects that this team is working on at one time. At present I have an excel workbook with sheets that contain a whole bunch of graphs, both at an overall team and by-project level. It's clunky and I spend more time tweaking formulas and double checking calculations than I'd really like. As such, I'm interested to know if anyone has used a tool that can effectively produce these sorts of reports, burn-downs, and predictions across multiple projects. I've seen http://www.pivotaltracker.com/ do some nice things, and of course there's JIRA/Greenhopper, but I'm not aware of those being used to track the progress of multiple projects within one team. If anyone's got an idea of some tools, or has faced a similar problem before, I'd love to hear from you.

    Read the article

  • Rewriting software using Agile methodologies

    - by Asier
    Suppose you have to rewrite an entire application using Agile methodologies, how would you do it? I guess you could write a big bunch of user stories based in the behavior of your current system. And then implement them in small iterations. But this wouldn't mean that we have the requirements UP FRONT?? Also, when would you start releasing? Agile says we should release early and often, but it doesn't make much sense to release before the complete rewrite has been completed. Anybody has used Agile before to rewrite software? How did you do it?

    Read the article

  • Change Comes from Within

    - by John K. Hines
    I am in the midst of witnessing a variety of teams moving away from Scrum. Some of them are doing things like replacing Scrum terms with more commonly understood terminology. Mainly they have gone back to using industry standard terms and more traditional processes like the RAPID decision making process. For example: Scrum Master becomes Project Lead. Scrum Team becomes Project Team. Product Owner becomes Stakeholders. I'm actually quite sad to see this happening, but I understand that Scrum is a radical change for most organizations. Teams are slowly but surely moving away from Scrum to a process that non-software engineers can understand and follow. Some could never secure the education or personnel (like a Product Owner) to get the whole team engaged. And many people with decision-making authority do not see the value in Scrum besides task planning and tracking. You see, Scrum cannot be mandated. No one can force a team to be Agile, collaborate, continuously improve, and self-reflect. Agile adoptions must start from a position of mutual trust and willingness to change. And most software teams aren't like that. Here is my personal epiphany from over a year of attempting to promote Agile on a small development team: The desire to embrace Agile methodologies must come from each and every member of the team. If this desire does not exist - if the team is satisfied with its current process, if the team is not motivated to improve, or if the team is afraid of change - the actual demonstration of all the benefits prescribed by Agile and Scrum will take years. I've read some blog posts lately that criticise Scrum for demanding "Big Change Up Front." One's opinion of software methodologies boils down to one's perspective. If you see modern software development as successful, you will advocate for small, incremental changes to how it is done. If you see it as broken, you'll be much more motivated to take risks and try something different. So my question to you is this - is modern software development healthy or in need of dramatic improvement? I can tell you from personal experience that any project that requires exploration, planning, development, stabilisation, and deployment is hard. Trying to make that process better with only a slightly modified approach is a mistake. You will become completely dependent upon the skillset of your team (the only variable you can change). But the difficulty of planned work isn't one of skill. It isn't until you solve the fundamental challenges of communication, collaboration, quality, and efficiency that skill even comes into play. So I advocate for Big Change Up Front. And I advocate for it to happen often until those involved can say, from experience, that it is no longer needed. I hope every engineer has the opportunity to see the benefits of Agile and Scrum on a highly functional team. I'll close with more key learnings that can help with a Scrum adoption: Your leaders must understand Scrum. They must understand software development, its inherent difficulties, and how Scrum helps. If you attempt to adopt Scrum before the understanding is there, your leaders will apply traditional solutions to your problems - often creating more problems. Success should be measured by quality, not revenue. Namely, the value of software to an organization is the revenue it generates minus ongoing support costs. You should identify quality-based metrics that show the effect Agile techniques have on your software. Motivation is everything. I finally understand why so many Agile advocates say you that if you are not on a team using Agile, you should leave and find one. Scrum and especially Agile encompass many elegant solutions to a wide variety of problems. If you are working on a team that has not encountered these problems the the team may never see the value in the solutions.   Having said all that, I'm not giving up on Agile or Scrum. I am convinced it is a better approach for software development. But reality is saying that its adoption is not straightforward and highly subject to disruption. Unless, that is, everyone really, really wants it.

    Read the article

  • How to handle multiple projects in a small team

    - by meo
    We just started to use scrum for our project management. We are a very small team (2 developers, 1 UI/Web-deisgner ) and we have a lot of running projects at once. How do you handle having multiple projects running at once in the scrum model? Most of the time we have a main projects and some small ones. How do you combine multiple sprints efficiently? PS: I'm not sure stackoverflow is the right place to ask this kind of question, i hope there is a scrum master out there reading this.

    Read the article

  • Do you know when to send a done email in Scrum?

    - by Martin Hinshelwood
    At SSW we have always sent done emails to the owner/requestor to let them know that it is done. Others who are dependent on that tasks are CC’ed so they know they can proceed. But how does that fit into Scrum?   Update 14th April 2010 Rule added to Rules to better Scrum with TFS If you are working on a task: When you complete a Task that is part of a User Story you need to send a done email to the Owner of that Story. You only need to add the Task #, Summary and link to the item in WIWA. Remember that all your tasks should be under 4 hours, do spending lots of time on a Done Email for a Task would be counter productive. Add more information if required, for example you may have completed the task a different way than previously discussed.  Make sure that every User Story has an Owner as per the rules. If you are the owner of a story: When you complete a story you should send a comprehensive done email as per the rules when the story had been completed. Make sure you add a list of all of the Tasks that were completed as part of the story and the Done criteria that you completed. If your done criteria says: Built Successfully 30% Code Coverage All tests passed Then add an illustration to show this. Figure: Show that you have met your Done criteria where possible.   This is all designed to help you Scrum Team members (Product Owner, ScrumMaster and Team) validate the quality of the work that has been completed. Remember that you are not DONE until your team says you are done.   Technorati Tags: SSW,Scrum,SSW Rules

    Read the article

  • What's a good tool for Scrum Project Management in game development? [closed]

    - by BleakCabalist
    I'm looking for an efficient, easy-to-learn tool for Scrum project management not for proffesional use but to use it in my thesis concerning the use of Scrum in game development. Basically I want to visualize a production process of a hypothetical game. Some fragments of the production process should be really detailed to make my point, so basically user stories, tasks, burndown charts etc. are a must. I'm using Scrum, Kanban and some Lean practices for eliminating waste. I also want to use Extreme Programming practices in this production process including TDD and Continuous Integration. I have zero experience in proffesional project management so I need something that's fairly simple to use for a newb like me. Anyone can recommend a tool like that? For now I was thinking about TargetProcess and ScrumWorks. Thanks.

    Read the article

  • Winforms Which Design Pattern / Agile Methodology to choose

    - by ZedBee
    I have developed desktop (winforms) applications without following any proper design pattern or agile methodologies. Now I have been given the task to re-write an existing ERP application in C# (Winforms). I have been reading about Domain Driven Design, scrum, extreme programming, layered architecture etc. Its quite confusing and really hard (because of time limitations) to go and try each and every method and then deciding which way to go. Its very hard for me to understand the bigger picture and see which pattern and agile methodology to follow. To be more specific about what I want to know is that: Is it possible to follow Domain Driven Design and still be agile. Should I choose Extreme programming or scrum in this specific scenario Where does MVP and MVVM fits, which one would be a better option for me

    Read the article

  • Need post-it notes that don't fall off the whiteboard after a week.

    - by jdv
    In my company, we plan our develpment work with scrum. We track progress using post-it stickies on a big whiteboard, and it works great. It is my understanding that's kind of standard. We are just one location, so we don't need or want to do this electronically. But to our (and the Q/A rep's) annoyance, the sticky notes begin to fall off the whiteboard after a week or two, or even sooner if you stick them on top of each other. I've experimented with extra tape on the stickies. That helped, but it also ruins the whiteboard. So I am looking for a pragmatic and preferably low-cost alternative. Are some post-it brands better than others? Or do you have another solution for a scrum board does not suffer from this?

    Read the article

  • Which tool to receive customer requirements

    - by Yoann. B
    Hi, In my company we want to use Scrum lifecycle, we are using Team System 2010. Team System is great to manage projects developpment and Scrum lifecycle. However we are looking for a solution in order to take care of customers requirements. A tool which give the ability to customer to send us their requests so we can plan it for next sprint. Should i use TFS Web Access ? but which type of Work Item ? I think TFS in general (not only Web Access) is for developpment team, not for customers ... Any idea ? Thanks in advance.

    Read the article

  • When using Microsoft Test Manager 2010 with SfTS, how do QA engineers know what tests they have to run?

    - by MADCookie
    We are moving our projects to TFS 2010 using the SfTS v3 (Scrum for Team System) template. We need to understand how Microsoft Test Manager is supposed to be used in this Scrum process. Specific scenario & question: The QA manager uses Test Manager to create Acceptance Test Work Items (WIs). These new WIs are created and "assigned to" him. The manager doesn't run all the tests, instead he wants to give that responsibility to his staff. How is a QA engineer supposed to know that he has tests to run? Everything says it is assigned to the manager.

    Read the article

  • How many months of fixing somebody else's bugs would you endure?

    - by Hamish Grubijan
    I understand that fixing bugs is a way to learn the system for the new people. But what if the system is so large that you can fix other people's bugs for 2 years and still not learn about every aspect of it? I would imagine that most people would get bored and not give their 100% to fixing bugs caused by others. Is there something wrong with the process? Everybody is chanting "Scrum! Scrum!" and getting certified, but that is just another phrase to me. How do you get noticed if all you do is fix bugs? Stand by a water-cooler perhaps and brag about how cool my bug fixes are? My political beliefs seem to be opposite from everybody else's at the company, and I have zero interest in pop culture/trivia/Tiger Woods scandals - there goes my opportunity to socialize during a lunch hour.

    Read the article

  • Cowboy Agile?

    - by Robert May
    In a previous post, I outlined the rules of Scrum.  This post details one of those rules. I’ve often heard similar phrases around Scrum that clue me in to someone who doesn’t understand Scrum.  The phrases go something like this: “We don’t do Agile because the idea of letting people just do whatever they want is wrong.  We believe in a more structured approach.” (i.e. Work is Prison, and I’m the Warden!) “I love Agile.  Agile lets us do whatever we want!” (Cowboy Agile?) “We’re Agile, but we use a process that I’ve created.” (Cowboy Agile?) All of those phrases have one thing in common:  The assumption that Agile, and I mean Scrum, lets you do whatever you want.  This is simply not true. Executing Scrum properly requires more dedication, rigor, and diligence than happens in most traditional development methods. Scrum and Waterfall Compared Since Scrum and Waterfall are two of the most commonly used methodologies, a little bit of contrasting and comparing is in order. Waterfall Scrum A project manager defines all tasks and then manages the tasks that team members are working on. The team members define the tasks and estimates of the stories for the current iteration.  Any team member may work on any task in the iteration. Usually only a few milestones that need to be met, the milestones are measured in months, and these milestones are expected to be missed.  Little work is ever done to improve estimates and poor estimators can hide behind high estimates. Stories must be delivered every iteration, milestones are measured in hours, and the team is expected to figure out why their estimates were wrong, even when they were under.  Repeated misses can get the entire team fired. Partially completed work is normal. Partially completed work doesn’t count. Nobody knows the task you’re working on. Everyone knows what you’re working on, whether or not you’re making progress and how much longer you think its going to take, in hours. Little requirement to show working code.  Prototypes are ok. Working code must be shown each iteration.  No smoke and mirrors allowed.  Testing is done in lengthy cycles at the end of development.  Developers aren’t held accountable. Testing is part of the team.  If the testers don’t accept the story as complete, the team can’t count it.  Complete means that the story’s functionality works as designed.  The team can’t have any open defects on the story. Velocity is rarely truly measured and difficult to evaluate. Velocity is integral to the process and can be seen at a glance and everyone in the company knows what it is. A business analyst writes requirements.  Designers mock up screens.  Developers hide behind “I did it just like the spec doc told me to and made the screen exactly like the picture” Developers are expected to collaborate in real time.  If a design is bad or lacks needed details, the developers are required to get it right in the iteration, because all software must be functional.  Designers and Business Analysts are part of the team and must do their work in iterations slightly ahead of the developers. Upper Management is often surprised.  “You told me things were going well two months ago!” Management receives updates at the end of every iteration showing them exactly what the team did and how that compares to what' is remaining in the backlog.  Managers know every iteration what their money is buying. Status meetings are rare or don’t occur.  Email is a primary form of communication. Teams coordinate every single day with each other and use other high bandwidth communication channels to make sure they’re making progress.  Email is used only as a last resort.  Instead, team members stand up, walk to each other, and talk, face to face.  If that’s not possible, they pick up the phone. IF someone asks what happened, its at the end of a lengthy development cycle measured in months, and nobody really knows why it happened. Someone asks what happened every iteration.  The team talks about what happened, and then adapts to make sure that what happened either never happens again or happens every time.   That’s probably enough for now.  As you can see, a lot is required of Scrum teams! One of the key differences in Scrum is that the burden for many activities is shifted to a group of people who share responsibility, instead of a single person having responsibility.  This is a very good thing, since small groups usually come up with better and more insightful work than single individuals.  This shift also results in better velocity.  Team members can take vacations and the rest of the team simply picks up the slack.  With Waterfall, if a key team member takes a vacation, delays can ensue. Scrum requires much more out of every team member and as a result, Scrum teams outperform non-Scrum teams working 60 hour weeks. Recommended Reading Everyone considering Scrum should read Mike Cohn’s excellent book, User Stories Applied. Technorati Tags: Agile,Scrum,Waterfall

    Read the article

  • Scrum et les changements pendant un sprint - Traiter les changements en flot continu avec une dose d

    L'agilité se définit souvent comme la capacité à répondre aux changements. Par exemple, Scrum permet au client d'incorporer des changements dans le périmètre fonctionnel à chaque fin de sprint. Le paradoxe, c'est que nombreuses de ces équipes sont dans un mode de changements quasi-permanents. Cet article expose des pistes leur permettant une transition plus douce en introduisant une dose de Kanban dans un cadre Scrum.

    Read the article

  • kanban scrumish tool(s) to get started

    - by Davide
    After investigating a little bit scrum and kanban, I finally read this answer and decided to start using kanban, picking something from scrum (note that I'm working mostly by myself, and I do have read this question and its answers). Now, my question is: which tool would be best to get started? whiteboard and postit agilezen.com JIRA with greenhopper a spreadsheet (possibly on Google Docs) brightgreenprojects.com Agilo Target Process something else (please specify) Notes about each: I would lean towards the whiteboard, but there are several drawbacks (e.g. cannot make automatic charts, time measurements, metrics, and sometimes I work from home - where I need it most - and it's not convenient to carry :-) I don't want to remember another username/password (I promised to myself to signup only to OpenID-enabled services) My employer has JIRA but my group doesn't use it - I might ask for an account (it shouldn't require another password) and maybe later involve the rest of the group. But I don't know if they are using greenhopper and if it's a big deal installing it. I generally hate spreadsheets maybe overkill? I'd be happy to have a localhost instance, but it could be problematic to give access to the whole group (per network/firewalls) - not a deal-breaker but surely a concern What I'd like to get from this? being more productive tracking how much time I spend in any given task, possibly discussing the issue with my supervisor tracking what "blocks" me most often immediately see where I am compared to my schedule manage in a better way my long todo list (e.g. answering faster to the "what I should do next?" question) Do you have any suggestion? Note on the scrumish tag: read the Henrik Kniberg's PDF. He first introduced the definition of scrumish on page 9.

    Read the article

  • Sprint velocity calculations

    - by jase
    Need some advice on working out the team velocity for a sprint. Our team normally consists of about 4 developers and 2 testers. The scrum master insists that every team member should contribute equally to the velocity calculation i.e. we should not distinguish between developers and testers when working out how much we can do in a sprint. The is correct according to Scrum, but here's the problem. Despite suggestions to the contrary, testers never help with non-test tasks and developers never help with non-dev tasks, so we are not cross functional team members at all. Also, despite various suggestions, testers normally spend the first few days of each sprint waiting for something to test. The end result is that typically we take on far more dev work than we actually have capacity for in the sprint. For example, the developers might contribute 20 days to the velocity calculation and the testers 10 days. If you add up the tasks after sprint planning though, dev tasks add up to 25 days and test tasks add up to 5 days. How do you guys deal with this sort of situation?

    Read the article

  • Scrum for Team System 2010 - How to use story points instead of Hours

    - by dretzlaff17
    I have installed TFS 2010 using the Scrum for Team System v3. The work item templates want you to enter a Project Backlog Item that includes story points, then you need to add linked tasks as a child of the PBI. It is at the task level where you can assign team individuals, update estimated hours left, etc. What is the importance of the Story Points used at the PBI item if individual tasks are using hours? Has anyone customized this template so that the child work item tasks use story point burn downs instead of hours? Also, I would be nice to have the total number of story points from each individual task roll up into the PBI item as a read only field for total story points. Thanks for your time.

    Read the article

  • When should the BDD test scenarios be written?

    - by Si Keep
    I am looking into BDD testing within a scrum scenario and realise that the BDD scenarios are more akin to specifications than tests. Therefore should they be written before the developers go into pre-planning so that all of the functionality has been identified which would allow better estimating, prioritisation etc in that meeting?

    Read the article

  • How to do a burndown chart for the whole project in Visual Studio 2010?

    - by Marsharks
    I am very new to using Agile (scrum). we have planned iterations using story points, but have not assigned work (tasks) to all the user stories in the project, just in the iteration coming up. My boss wants to know how much work is left to do...and I don't know because I haven't planned those iterations. Can anyone give me advice or a resource to reference on what I need to do in order to provide him with what he needs?

    Read the article

  • Writing user stories for internal technical tasks

    - by John Nolan
    I am attempting to manage my projects a little better so I am looking at attempting to apply some of (eventually all) the features of scrum. Looking at user stories specifically the high level format seems to be: As a User I can Feature Description or Artifact is Doing Something How would I write "Upgrade the Database"? Is it simply Upgrade the Database? I think I am being thrown off as there is no specific actor/customer and that the customer is the IT department.

    Read the article

  • SSW Scrum Rule: Do you know to use clear task descriptions?

    - by Martin Hinshelwood
    When you create tasks in Scrum you are doing this within a time box and you tend to add only the information you need to remember what the task is. And the entire Team was at the meeting and were involved in the discussions around the task, so why do you need more? Once you have accepted a task you should then add as much information as possible so that anyone can pick up that task; what if your numbers come up? Will you be into work the next day? Figure: What if your numbers come up in the lottery? What if the Team runs a syndicate and all your numbers come up? The point is that anything can happen and you need to protect the integrity of the project, the company and the Customer. Add as much information to the task as you think is necessary for anyone to work on the task. If you need to add rich text and images you can do this by attaching an email to the task.   Figure: Bad example, there is not enough information for a non team member to complete this task Figure: Julie provided a lot more information and another team should be able to pick this up. This has been published as Do you know to ensure that relevant emails are attached to tasks in our Rules to Better Scrum using TFS.   Technorati Tags: Scrum,SSW Rules,TFS 2010

    Read the article

< Previous Page | 4 5 6 7 8 9 10 11 12 13 14 15  | Next Page >