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 ...


15

Keep in mind the overarching goals: in the end, only working software matters Peer review and check-in code review have the goal to improve quality. But there's nothing worse for quality than a demotivated developper. As a team lead, your role is not to endorse the code as something that you could have written yourself, but to promote teamwork and ensure ...


15

The basic Six Sigma activities are captured by the acronym DMAIC, which stands for: Define, Measure, Analyze, Improve, Control. You apply these to the process that you want to improve: define the process, measure it, use the measurements to form hypotheses about the causes of any problems, implement improvements, and ensure that the process remains ...


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 ...


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 ...


6

A couple thoughts from the school of hard knocks: 1) Most process improvement initiatives spend 80% of their time on process design and 20% on education and socialization. Flip these percentages. A mediocre standard that's followed beats a perfect one that isn't. 2) Identify clear reasons why you're asking people to change how they work. What's the ...


4

Since N can be as large as 10^12 it should have been clear that iterating from 1 to N is not the desired solution. The key insight is that the recursion can be rewritten as V(i) = M * V(i-1), where V(i) = [RR(i), MM(i), PP(i)] (a column vector) so V(0) = [ 3 1 0 ] and M = | 1 0 3 | | 1 0 2 | | 0 5 0 | Now V(N) = M^N * V(0) We can ...


3

As developers we are, the mindset should remain always open and sceptical at the same time. Open, because we don't know when a developer may surprise us, and sceptical about our own ideas because we often forget that in software engineery there's not a single correct way to implement a solution. The rationale behind our solutions could make sense for us ...


3

what is the most important for conducting the postmortem of my project, meeting "physically" or not doing it two months after? Since you are doing everything over video link (I assume using skype or similar), then you should be quite comfortable doing it that way. The physical presence is not really necessary. But it is important to conduct it as soon as ...


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

If they have competitors, then performance is a major criterion by which they are judged. By the way, if you think performance is a matter of using switch vs. if, you're missing the point by an enormous margin. You don't know what to fix in the code until you find out what takes time. That can seldom (i.e. never) be done by eyeballing the code. What I do ...


3

Have you tried (company-wide) retrospectives? Generally, it's a moment where the team comes together, usually after a sprint, to discuss what went well, what didn't go well, what they should start doing, what they should do more, what they should stop doing. At the end, you should have one or two actionable improvements to implement for the coming sprint. ...


2

Start software process improvement (SPI) project. Define its scope and goals. It will definitely help if standardization has its own goals and measure applicable to your organization. Assign person responsible for adopting standards. It also might be several people or even department in the case of large organization. Important thing is that all those ...


2

Basing your efforts on the CMMI is probably a good idea, even if you don't undergo the appraisals and get formally audited and rated. There's plenty of literature available about the CMMI, CMMI and other process improvement techniques such as Lean and Six Sigma, and CMMI and agile software development. The SEI has an entire collection of resources, some ...


2

The Sprint planning meeting has 2 parts: Decide what the team will do Decide how the team will do it. The first part is relatively straight forward--based on the number of story points the team feels they can take on, the commit to completing that many user stories in their order of priority. Done. The second part is what developers should actually enjoy-...


2

Meddling with developer's code for cosmetic changes will demotivate the developer but in absolute circumstances it has to be done. The lead has to find the balance between providing useful code review and learning to let go of minor shortcomings. https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/


1

Some things to keep in mind: It is about psychology as much as about technology, so there is no golden rule here. What is about people is not just about knowledge but also about culture and position in hierarchy. If this is a "long" game (stable and established company), well integrated team where people trust each other usually has higher value than the ...


1

Embedded development. When you're working with a tiny memory footprint and real time requirements you have to constantly be thinking about every aspect of performance, both speed and memory. Real time embedded devices often require response times in the order of milliseconds in my experience. If a routine is off running for 10 seconds somewhere, you've ...


1

Projects that have performance requirements. It really doesn't matter what the hardware is. I can drive anything to 100% utilization. Same as I can fill any hard drive. The question is, can I ignore performance and still hit my performance goals. If yes, I am justified in ignoring performance. Some projects find they have performance problems. If they ...


1

What is most important for conducting the postmortem of a project, use a conferencing solutions to perform the postmortem remotely or wait for two months until the team can meet in person? Personally, I think meeting people in person breaks down a lot of barriers and empowers each person to contribute to the discussion. In my own experience, I've seen ...


1

Yea I know this is an old question, but I have a new answer. :P Split the meeting up. We split our Sprint planning meeting into 3 separate mini-meetings Backlog grooming Story selection Task breakdown We do each on a different day, right after our daily Scrum - as soon as the daily is done, we roll right into the planning activity, and then we are ...


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