33

Why are the backlog items not inserted and prioritized before sprint kickoff? Wasting developers time is not fun. Let your team leads work with the product owner and project manager a few days beforehand to prioritize stuff. This goes for planning who is on each sprint team too. Why is it taking a day to break things out into tasks? If you have a reasonably ...


30

Make estimating easier Break your sprint planning down. Do you need to estimate the individual tasks? I've done sprint planning two ways: Stories are estimated in story points and then tasks are estimated in hours Stories are estimated in story points and tasks simply fall under that with no estimate Of the two, I prefer the second option. I find that ...


21

Ideally, the scrum master is responsible for facilitating the project activities and to address any sort of impediments faced during that. He/she does not participate in the "yesterday, today, impediments" spiel during the daily stand-up per se, however, is answerable to the team members for any kind of status on the impediments they have reported during ...


18

a) I will find out what the answer to this is from the person responsible for that area of the project and get back to you within the next two days b) This is a good point, thank you for raising it. I have not thought about this aspect but will do and get back to you within the next two days c) What do you actually mean about this as it does not seem to ...


14

"As long as they need to be, and no longer." The thing to realize here is that meeting time to saved development time is in no way linear. For your team, for your company, for this topic, then 1 hour of meetings might save 2 hours of dev work. If you have 10 hours of meetings, another hour of meetings might save 0 dev work. Hell, it may save you -2 hours of ...


13

For Scrum, Ken Schwaber and Jeff Sutherland explain: Daily Scrum The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily ...


10

Planning is one area of scrum where teams have a lot of flexibility. Try something new every sprint until you hit on something that works for your team. Some successful ideas I've either tried personally, or heard about from other teams: Do user story creation and prioritization without the entire team. The product owner and/or scrum master can handle a ...


10

The original idea of the daily standup is certainly to do it in person, because this enables a communication channel with way more bandwidth then anything based on writing. Having that said, doing it in writing via mail, chat or similar can be a great choice if it actually solves problems you have with the face 2 face communication. Especially with vastly ...


8

You mentioned three types of questions: a) you do not know the answer to: Tell them I don't know the answer, but that you will find out the answer. Then write down their question/concern and get back to them quickly. b) you have not thought about for one reason or another: Tell them that is an interesting idea. Then write it down and followup quickly. c) ...


8

I agree wholeheartedly. Almost every table in every database should have at least 2 fields: the creation date and update date. There are many reasons that you should put a create date and update date. For obvious reasons that prior people stated…which is audit. I have been designing systems and databases for 25 years and have worked for hundreds of ...


8

You said that the meetings feel like you are lecturing them. If it feels that way to you, and the team doesn't seem interested in what you have to say, then why still have the meeting? If you're just throwing information at them, and it isn't holding their attention, why not just summarize everything in a weekly email instead? If you want to make use of ...


8

TL;DR When properly executed within an appropriately-sized Scrum team, the daily stand-up should never take more than 15 minutes or so. If it takes longer, either the team is too big or you have a process problem. The Purpose of the Stand-Up The daily stand-up is a commitment and coordination meeting for the entire team. It is designed to ensure that the ...


7

Your planning sessions are way too long! Based on my experience, a sprint planning meeting should take no more than 2 hours per week being planned (e.g. a 2 week sprint should take 1/2 day at most), but successful ones should be shorter than that (half of it). In your particular case: why are you estimating tasks? You should estimate only stories during ...


7

Scrum considers the Daily Scrum to be an inspection and planning meeting. The purpose is to inspect the work done against the Sprint Goals and to plan the next day's worth of work. The three questions are just one method of running a Daily Scrum and are not required. The Scrum Master should be coaching the Development Team on an effective way to execute the ...


6

Triaging is not typically done as a meeting. Teams do it differently, depending on the product, but on our team, the product owner triages the customer issues, and we rotate another team member as "triager of the day" for issues that testing finds. The triager's job is not supposed to be debugging, but answering the following questions as efficiently as ...


6

Not exactly. Understanding the customer/stakeholder can save development time. And conversations need to be long enough to facilitate understanding. But, discussing a feature you already presume to understand will not necessarily improve your understanding. If no one in the room has any suspicions of misunderstanding or false assumptions, leave the room. ...


5

As per the Scrum Guide content on daily standups, the three questions for discussion are: What did I do yesterday that helped the Development Team meet the Sprint Goal? What will I do today to help the Development Team meet the Sprint Goal? Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal? All of the ...


4

Stop wasting time! The main point I want to make is that the more people you have in a meeting, the more time you are wasting. Whenever you are discussing something not directly relating to employee X, you are wasting employee X's time. Why is this a bad thing? Obviously there is a direct cost (assuming you are paying employee X for his/her time!) but ...


4

Several years ago I have worked in a place where it was usual to put whole teams into meetings, just for the sake not to exclude anyone. Now, for almost ten years I work in a place where only those persons meet who really need to discuss things together, and other team members are only invited occasionally (and not for the whole meeting) to discussions about ...


4

Welcome to the world of middle management! You are going to find this type of problem happening a LOT! You have 3 options: Big Stick Do this or you are sacked - never works. Don't do it. Ownership Get them to facilitate the meetings. Take a step back and nominate someone else. Have it as a rotating position where a different person hosts each time. ...


4

There are many factors which contribute to the tension over meetings. Consider these as some of the important reasons why meetings may be costing you more than they are worth: Focus - software versus meetings Management - managers need measurement Personality - Introverts vs. Extroverts Time - interrupts, Maker and Manager time Goals, Priorities Each of ...


4

Frankly, in 99% of the daily scrum meetings I've gone to, pretty much all the discussion/questions/answers could have been remedied with a few emails. I honestly think we need to show more valid reasons to NOT have meetings. Build environments where when it's time to corral everyone into a room in-person, that it had better be a good reason and be ...


4

I've managed and been a part of scrum teams many times. The key reason developers don't like scrum are: Because they run by a very poor scrum master, if it turns into 45 minutes your scrum master needs to improve at controlling the scrum. The biggest and by far THE most honest reason why they don't like it, is because it's very hard to hide in a bad work ...


4

For knowledge-intensive, fast paced conversations, use whatever recording / capturing devices you can. In one of my past projects, our professional tech writer used audio recording to capture explanations from our lead developer. Guides he produced were great. Few months ago I brainstormed design of a particularly tricky module with my tech lead. After we ...


4

This happens to everyone from time to time, no matter how experienced or prepared. Honesty is the best policy in these situations, which means acknowledging you don't have the answers. You'll be a lot more credible in the long run than if you try to bluff your way through it. Specific questions: (a) If you don't know the answer, instead of just shrugging ...


3

The above suggestions are definitely great ones, and work well in most contexts. Like the other responders indicated this is bound to happen - especially if you are presenting ideas to smart people and looking for their critique or feedback (for example, trying to raise funding for a start-up). However you respond you want to achieve a few things: Retain ...


3

Combine your fastest method, in your case typing, with a voice recorder. Partially complete any section where the lead is going too fast, tap your recorder so it makes a CLACK and you can find it easily, then fill in the details later.


3

At my previous job, the entire first day of each sprint (we called them iterations there) was taken up with: Retrospective. We started out doing this in the afternoon of the last day, but we often found ourselves retrospecting about the sprint and then going back to work tying up the last loose ends of that sprint's work, so we figured it would be better to ...


3

As a sole developer, your biggest issue is visibility. My recommendation is to do full sprint cycles, like in an Agile project. Every two weeks, demo a little bit more functionality (this could be in a half hour to hour long meeting. Every day have a standup explaining what you did yesterday, what you'll be doing today and any roadblocks you have. By ...


Only top voted, non community-wiki answers of a minimum length are eligible