Story points should reflect the complexity and effort required to complete the story. If points are purely based on complexity, it can inaccurately represent a relatively simple task that requires a lot of repetitive effort. If points are purely based on effort, it may not reflect the potential risks involved with the complexity of the task.
Story points should be relative to a reference story (it should not necessarily correlate to the number of task hours). The number of hours are dependent on who works on the story, so story points should be based on a another story. Attempting to correlate the two will lead to extra work with little or no value if there are more than one member in a team.
The numbers should accurately represent the size relationship for better velocity estimation. For example, if we use story pointing system (1, 2, 4, 8), a story with 4 points should be about double the [effort/complexity estimation of] story with 2 points. The point system should not start with 0 because a hundred 0 point stories adds 0 points to the team velocity. It should also not have granular differences for the larger numbers as this should be a rough estimation where some stories are slightly more or less than estimated.
I personally don’t like daily scrum in the mornings for a local team (without members in different timezones).
Early Morning Scrum
Late comers may miss stand up. Difficult to start work knowing stand up is in within 30 min after arrival.
Late Morning Scrum
Work day tends to start later as some members consider daily scrum time to be the beginning of the work day.
Early Afternoon Scrum
After lunch, team may have food coma. Probably the least productive time anyway.
Late Afternoon Scrum
Early goers may miss stand up. Team may develop a practice of checking out after stand up.
I think the best time is early afternoon, at least in my experience. Any impediments or announcements should be escalated immediately as they arise regardless of when daily scrum is held.
We use quickbooks for invoicing, and the new invoices were missing the “Service Date” column in the preview and the final invoice. I called Intuit support, waited ~20 minutes on hold, but eventually got the answer.
It seems like they’ve added a new feature that needs to be checked in order for the service date to show.
Gear Icon -> Company Settings -> Sales -> Sales form Content -> Service Date (on)
Also ensure Gear Icon -> Company Settings -> Sales -> Customize Sales Forms -> Activity Table Columns -> Date (on)
Mitigating risk and optimization is critical in project management. It is necessary to have a plan to control the unknowns.
How do you control the unknowns? Yes, they are difficult the control in the beginning, but this process can be improved with time and data.
First of all, there are known unknowns and unknown unknowns. The known unknowns are issues that you know could cause issues. For example, if our systems are getting upgraded tomorrow, there may or may not be an issue leading to more downtime than expected. The unknown unknowns are issues that arise that you haven’t even thought of. For example, hardware failure on your development machine could be an unknown unknown.
Known unknowns are much better than unknown unknowns. Mitigated risks are much better than known unknowns. We need to account for as many [realistic] unknown unknowns as possible and mitigate any and all risks associated with them.
This is why planning is extremely important in Agile teams. Make sure you allocate time to keep track of the unplanned activities, unknown unknowns that occurred, and the level of impact of the known unknowns. As more data is collected, have them accessible for future use.
Padding time is a no-no, but if it might be ok when we start calculating the risks. I’m sure there’s some equation for risk mitigation that uses something like the expected value in statistics. I’ve worked for projects that used metrics of anywhere between 50%-75% utilization of actual available development time. This number shouldn’t be random, it should be carefully calculated and adjusted as the project progresses.
When the unknowns do occur, shelter as many people as possible from these risks, so the schedule is minimally impacted.
Networking is important. The world stressed this enough throughout my life. But is it really?
Networking is useless without a specialty. What will they remember you by? Why should they talk to you again? How can they help you when you offer no services?
You need a specialty. Something people can remember you by, something valuable you can offer that others can’t.
Then you need to broaden your scope. Something to differentiate you from the other specialists.
Because “luck is what happens when preparation meets opportunity,” and this is when networking is important.
I use this term often. What I mean is a large-scale project that is difficult for a single person to grasp every aspect of it. It requires the interaction of many architects to fully grasp the implementation and impact of changes.
I personally use the word enterprise-grade interchangeably.