Tag Archives: Teams

Engineering Teams

What makes a meaningful standup update?

Leave a comment

Hey there! I know it can be difficult to know what to say in standup. One of the most important things you can do to keep your team in the loop is to share a meaningful standup update on your progress. Think of it like a relay race – each team member needs to know where the baton is, how fast it’s moving, and whether there are any obstacles ahead.

When I enter standup and giving my update, I like to ponder: “What info can I give to the team that might be meaningful for a standup update?”

Tips for sharing meaningful standup updates

  1. Update the team on your current work status
    Let your team know how close you are to meeting milestones, deadlines, and if you’ve encountered any issues. For example, “I’m 85% complete with the License/phone selector for site settings and should have it ready for review by tomorrow morning.”
  2. Communicate any changes that may impact others
    Let your team know of any changes to your work that may impact or unblock the work of others. For example, “I’ve finished the API bits for both site and account phone/license, which should now unblock the UI stories for the rest of the team.”
  3. Customize your updates
    Tailor your updates to your team members’ interests and needs. For example, provide more details on a technical challenge for a team member who’s interested.
  4. Be proactive in sharing updates or asking questions
    Don’t wait for someone to ask for an update. For example, “I wrote up a bug I believe I noticed a bug in production, I would like to see if we should address it now or a future sprint.”
  5. Provide context
    Share not only what you’ve done but why you’ve done it. Providing context can help non-technical team members better understand the value it brings, and how it fits into the overall vision. For example, “I’ll be starting work on the date pickers, this is part of the new reporting view we’re building.”

Why do Good Standup Updates matter, you ask?

Well, here are a few reason:

  • Keep your team up-to-date
    Regular updates help everyone stay informed about the progress of the project and any potential roadblocks.
  • Identify and address issues early
    Sharing updates on any issues or challenges you’re facing can help your team address them early on, preventing them from becoming bigger problems down the line.
  • Foster team cohesiveness
    Sharing updates can help your team understand each other’s work and goals, leading to better communication and collaboration towards a shared vision.

“The single biggest problem in communication is the illusion that it has taken place.”

– George Bernard Shaw (1856 to 1950)

So, the next time you’re in a standup meeting, don’t just rattle off a list of tasks you completed – instead think of your standup updates like a baton in a relay race – an opportunity to keep everyone informed, stay on track, and work together to reach the finish line.

Ask yourself: “What info can I give to the team that might be meaningful for a standup update?” and you’ll build a strong team culture that values open communication and collaboration, leading to more productive and successful projects.

Book Reviews

Become an Effective Software Engineering Manager – Book Review

Leave a comment

Become an Effective Software Engineering Manager is an essential guide for learning to grow and lead engineers.

This is the single best book I’ve read on what it means to be a great Engineer Manger. It’s an enjoyable and honest read.

Become an Effective Software Engineering Manager Book Cover

Rating

(Higher is better, 5 is neutral)

  • Would I recommend? 10 / 10
  • Did I learn anything? 10 / 10
  • Did I learn anything I can apply? 9 / 10
  • High Information density? 8 / 10
  • Would I re-read? 9/10

Buy Become an Effective Software Engineering Manager on Amazon

Become an Effective Software Engineering Manager Overview

The author will take you on a journey from day one to being a central influencing helping your team be the effective and impactful.

The book is broken down into 3 major sections: Managing Yourself, Working with and Managing others, Working with Teams and the Organization at Large.

Who should read Become an Effective Software Engineering Manager?

Certainly every Engineering Manager and Head of Engineering. This could be a playbook for creating a philosophy around great management.

Senior Engineers who are considering Engineer Manager route or want to build empathy with an Engineer Manager’s role.

My main takeaways

Being organized is very key to being a great manager. Use your calendar, email, reminders, and notes effectively. Specifically automated reminders will give you super powers.

You have two options for leading: The Stick or The Carrot. The Stick driving everyone forward with pressure & deadlines. The Carrot by motivating & aligning on mission.

There is a hierarchy of needs in the workplace. First two are Physiological (pay & benefits) and Safety (job security & environment. These two we have control over as manager, but don’t lead to long term job satisfaction. The next three are Belonging, Esteem, and Self-actualization. As managers we can contribute to these fulfilling items by finding opportunities that align with a reports interests.

There tends to be two developer archetypes: Cathedra Builders and Bazaar Browsers. Those that want to go deep and be a subject master, building towards perfections; and later are those that desire for exciting new things and never want to be stagnant. Each have their space in an organization and both are motivated in their own ways. Don’t try to fit one in the others role for long if you can help it.

Delegation has a range of levels of oversight. From no oversight to showing another how to do a task. Closing the right level of delegation depends on the task and the individuals capabilities.

If you liked this book, next I’d recommend:

Going deeper on team culture: Elegant Problem
Going deeper on leading with positive impact: Multipliers
Going deeper on project management: Waltzing with Bears

Book Reviews

Debugging Teams – Book Review

Leave a comment

Debugging Teams is a short, clean, and to the point read. It’s a great book to pick up, read a page or two & set down and ponder. Every section speaks lightly, yet bluntly about team culture & being a great team member.

Debugging Teams Book Cover

Rating

(Higher is better, 5 is neutral)

  • Would I recommend? 9 / 10
  • Did I learn anything? 8 / 10
  • Did I learn anything I can apply? 7 / 10
  • High Information density? 8 / 10
  • Would I re-read? 7/10

Buy Debugging Teams on Amazon


Debugging Teams Overview

Debugging Teams speaks honestly and cuts to the chase. It provides practical advise with how to work with (and around) bad culture and defines what good culture looks like.

It reminds us that good team culture starts with ourselves. We have to be humble to grow ourselves to be an example of what good culture is.

Debugging Teams sets that bar of what that good team culture should looks like and thusly what bad culture looks like.

Who should read Debugging Teams?

Pretty much everyone! Specifically leadership, managers, and junior to senior devs.

I consider this essential reading for any of team member as an introduction to thinking about team culture.

My main takeaways

Culture is important from day 1, bad culture from one teammate infects an entire team and pushes away good talent. It’s hard & nearly impossible to override one toxic teammate with many good ones, it just doesn’t work.

Therefor don’t tolerate having the Brilliant Jerk on the team. They aren’t worth it. They set bad culture and diminish the team around them.

Be the example of the culture you’d like to see, be humble, you likely have faults as well. We need to be aware of our own ego.

If you liked this book, next I’d recommend:

Going deeper on team culture: Elegant Problem
Going deeper on leading with positive impact: Multipliers
Going deeper on project management: Waltzing with Bears
Going deeper on managing a team: Become an Effective Software Engineering Manager

Favorite Quotes

“Software development is a team sport”

“If you spend all your time working along, you’re increasing the risk of failure and cheating your potential for growth”

“Relationships always outlast projects”

“Understand the difference between constructive criticism of someones’ creative output and flat-out assaults against someone’s character. […] If you truly respect someone, you’ll be motivated to choose tactful, helpful phrasing.”

“Your self-worth shouldn’t be connected to the code you write – or any project you build.”

“When you stop learning, you get bored. It’s really easy to get addicted to being a leading player; but only by giving up some ego will you ever change directions and get exposed to new things. Be willing to learn as much as teach.”

“Admitting you’ve made a mistake […] is a way to increase your status over the long run.”

“A ‘strong culture’ is one that is open to change that improves it, yet is resistant to radical change that harms it”

pg 31

Book Reviews

Get Together – Book Review

Leave a comment

I rather enjoyed Get Together and recommend it often to my friends who find themselves leading communities. I’ve build several communities and indirectly followed some of the exact same patterns. Having this book as a guid would have been a huge help. Reading through it I’ve learned new ideas for forming strong communities.

Get Together Book Cover

Rating

(Higher is better, 5 is neutral)

  • Would I recommend? 8 / 10
  • Did I learn anything? 7 / 10
  • Did I learn anything I can apply? 7 / 10
  • High Information density? 6 / 10
  • Would I re-read? 8/10

Get Together on Amazon

Get Together Overview

There is a bit of a science to building strong thriving communities, and Get Together shares some of those patterns that can be implemented in nearly any scenario.

Get Together shares what they call the 3 phases of growing a community: Spark the Flame (Getting things started), Stoke the fire (Building strong community), Passing the torch (Empowering the next set of leaders)

Who should read Get Together?

Anyone who is either looking to, or already leading a group. Be it either social or in a work environment. If you are looking for ideas of how you might get your group off the ground or stoke your group to grow to the next level, this is a good read.

My main takeaways

Find core, excited people in your community and empower them to get involved and participating.

You can build a community about anything your passionate about, even a cloud fan group!

Make gatherings Purposeful, Participatory, and Repeatable.

Create a space to talk and provide prompts to keep conversation going.

Give members a sense of identity, giving tokens and ownership.

Empower the next set of leaders. You don’t need to lead forever.

If you liked this book, next I’d recommend

Building a multiplier team culture: Debugging Teams

Example of strong company culture: Creativity Inc.

Book Reviews

Multipliers – Book Review

1 Comment

Multipliers captures one of my key values: Investing in others and empowering them to reach their full potential. I was very excited to find a book aligned with that very value, and it did not disappoint.

Rating

(Higher is better, 5 is neutral)

  • Would I recommend? 9 / 10
  • Did I learn anything? 8 / 10
  • Did I learn anything I can apply? 8 / 10
  • High Information density? 7 / 10
  • Would I re-read? 7/10

Buy Multipliers on Amazon

Multipliers Overview

Multipliers compares communication that build and unlock the potential of others and contrasts it agains communication that diminishes. By the end of the book you’ll have many tools to identify your strengths as well as weaknesses in which you can grow to better build your team up.

As a book, Multipliers feels a bit “corporate self-help” in nature akin to Enneagram or DiSC. At times the sections felt light and wordy. Nevertheless the ideas are fantastic and solicit self-reflection. It has many tips and examples to help transition diminishing patterns to multiplier patterns.

Who should read Multipliers?

Everyone could learn about themselves from Multipliers. Specifically managers, mentors, and leaders without a doubt should read Multipliers.

If you’re someone who leads people or aspires to lead, Multipliers will help you consider your blind spots you could level up to become an even more impactful leader.

My main takeaways

Even the best leaders can accidentally Diminish others around them.

Even though it comes form a good place, being too supportive & available can cause others to rely on you to ‘save the day’ and thus diminish their growth opportunity. Being less available and trusting challenges others to grow.

Hand back the pencil. Give the power back to others after you’ve contributed a thought. Don’t solve all of it, include them.

If you liked this book, next I’d recommend

Building a multiplier team culture: Debugging Teams

Example of multiplier company culture: Creativity Inc.

Engineering Teams

10 Great Topics for Engineering All Hands

Leave a comment

What are good Topics for Engineering All Hands?

Bringing together an engineering team is something we all can agree we should be doing. But how do make sure it’s not a waste of time?

We might ask many questions that will guide us in the direction to find topics for engineering all hands.

  • What updates are value for the team?
  • What topics should be presented?
  • What makes the teams feel involved or appreciated?
  • What information might the team not get elsewhere?
  • What would help align the team in a shared vision?
  • What formats make the most sense to present in?
  • What might excited the team?

Your team will be unique and will always be evolving to find new patterns of topics that gel well and are provide the most value. Ask your team what they would find valuable, experiment and try new things.

Here are several ideas of my ideas for topics for engineering all hands to get you started in running great engineering all hands.

10 Great Topics for Engineering All Hands

1. Impact of what has been built

This could be backed with numbers like sales, hours saved, etc.

Customer stories how they using what the team has been building. This could even involve bringing in real customers to meet the team and share their real life usage of the product.

2. User Feedback about what we’ve been built.

Similar to impact, however this might be reviews, tweets, emails, or feedback of what users are saying about the product we’re building.

3. Vision of why and what we’re building across teams at high level.

What are the business goals that we’re trying to meet?
How are team roadmaps satisfying those business needs?
What sort of things will be building over the next 3, 6, or even 12 months?

4. Light technical deep dive

Share big picture technical demos. This could be big projects, or ones that are good general knowledge sharing. Even though the Engineering All-Hands will mostly have technical folks, refrain from deep-diving too far, that might be better for a technical show-case. We have so many other things to share during the All Hands!

5. Updates around pay / careers / hiring

Are we planning on hiring team members?
What level are we hiring for and for which teams?
Are there updates about how careers are evaluated/structured?

6. Vision of how we want to be structured and grow as a product org

What are the Engineering Orgs vision of who we want to be, what our values are? How do we better ourselves and improve so that we might be one of the best Engineering Ors.

7. Opportunities to make an impact

Share needs that are across the entire Engineering organization as opportunities to get involved.

Are you forming a think tank group about coding standards? Want to form a team to plan an Engineering Off-Site Outing? Looking for volunteers to brainstorm a new product?

8. Recognition across all teams

What wins do teams have? Some may be customer facing, others interesting technical accomplishments. It’s important to recognize an entire team, not just individuals.

9. Promotion announcements

Celebrate team members who are growing! Promotions aren’t handed out lightly, with a good career band system they are tangible accomplishments. We should be proud and celebrate them!

10. New hire intros

This may have been also done at the Company wide level or at the team level. This is an opportunity to have fun intro at a technical level and across the entire Engineering organization.

Further Thinking

Who should be presenting at an Engineering All Hands?
How might presentation roles be shared?
How might an Engineering All Hands be interactive?
How do you Host a Great All Hands?

Book Reviews

Creativity INC. – Book Review

Leave a comment

Creativity Inc. is a delightful & fairly easy read. I enjoyed it, however didn’t get much practical value out of it.

Cover of Creativity Inc.

Rating

(Higher is better, 5 is neutral)

  • Would I recommend? 5 / 10
  • Did I learn anything? 5 / 10
  • Did I learn anything I can apply? 2 / 10
  • High information density? 3 / 10
  • Would I re-read? 3 / 10

Buy Creativity Inc. on Amazon

Creativity Inc Overview

Gems of information are tucked away amongst history around Pixar. You’ll have to sift through stories about Toy Story, Bugs Life, and other films along the way of finding ideas to ponder.

Reading this book you’ll learn more about Pixar’s history than what makes thriving creative workplace. Though

Who should read Creativity Inc?

If you love Pixar, I highly recommend Creativity Inc! You’ll have much deeper love and appreciation for everything they create.

However, I likely won’t be recommending to anyone for personal growth or learning. I may recommend it to Managers & Directors who are scaling a company up. It could be encouraging read to reflect on what team culture to defend and keep as well as how to adapt as an organization grows. Though this book doesn’t dive into concrete advise.

My main takeaways from Creativity Inc.

Creativity is fragile. Do not shut ideas down, give them safety and build upon them.

Self expression is important, allow folks to decorate their workplace and share their passions they have outside of work.

A select group of employees will “get it” and be rockstars, value them. However, I’m not sure if I agree with Pixar’s “Braintrust”. While open radical candor is very important, I feel it places a select few into an elite few. It doesn’t seem this is Pixar’s intent with the Braintrust since advise (“notes”) are optional. I think I’d rather a pattern when all can provide radical candor regardless of status. Creating a Braintrust creates an inner circle club.

If you liked this book, next I’d recommend:

Going deeper on team culture: Debugging Teams
Going deeper on leading with positive impact: Multipliers

Favorite Quotes

“[…] managers must loosen the controls, not tighten them. They must accept risk; they must trust the people they work with and strive to clear the path for them; and always, they must pay attention to and engage with anything that creates fear.”

“For all the care you put into artistry, visual polish frequently doesn’t matter if you aren’t getting the story right.”

“Finding and fixing problems should be assigned to every employee. […] ownership of and responsibility for a product’s quality to the people where most involved in its creation. […] You don’t have to ask permission to take responsibility.”

“If you give a good idea to a mediocre team, they will screw it up. If you give a mediocre idea to a brilliant team, they will either fix it or throw it away and come up with something better.”

“Find, develop, and support good people, and they in turn will find, develop and own good ideas.”

“You are not your idea, and if you identify too closely with your ideas, you will take offense when they are challenged. To set up a healthy feedback system, you must remove power dynamics from the equation – you must enable yourself, in other words, to focus on the problem, not the person.”

“Candor is only valuable if the person on the receiving end is open to it and willing“

“Failure, when approached properly, can be an opportunity for growth. […] To be wrong as fast as you can is to sign up for aggressive, rapid learning.”

“If we allow more people to solve problems without permission, and if we tolerate (and don’t vilify) their mistakes, then we enable a much larger set of problems to be addressed.”

“Managers, afraid of appearing to not be in control, believe that they have to know everything – or at least act like they do. […] The better approach, I believe, is to accept that we can’t understand every facet of a complex environment and to focus, instead, on techniques to deal with combining different viewpoints.”

Project Management

Why We Should Consider 1 Week Sprints.

Leave a comment

You know how 2 week sprints are the de-facto go-to pattern for many teams? I don’t believe they are the best for teams and we should all consider 1 week sprints instead, and I’ll tell you why.

The Downfalls of 2 Weeks Sprints

  • Longer meetings to plan for 2 weeks
  • Need more Context
  • Hard to estimate how much work can be accomplished
  • Over commitment is easy
  • Doesn’t accommodate changing requirements
  • Doesn’t accommodate newly discovered scope as well
  • Doesn’t accommodate surprises that pull for attention away from the team (support, external teams)
  • Can create anxiety when falling behind, especially considering work remaining
  • PMs have less certainty on sprint progress
  • Slow feedback cycle

The Upsides of 1 Week Sprints

  • Tighter feedback loops
  • Shorter meetings
  • Allows team to be more precise in their commitments
  • Forces team to think about the now (highest priority).
  • If scope or focus change occurs, only interrupts 1 weeks worth of work.
  • If over commitment occurs it is smaller and easier to correct.
  • Generally feels more exciting, each week starts anew.
  • Weekly routine lightens the mental load

Won’t 1 Week Sprints have more meetings?

Since we have only one week to plan for, we must have more meetings, and this take more time right? Surprisingly you’ll spend less time in meetings!

Touching base on a weekly basis there are fewer surprises and thus fewer ‘new’ topics that need to be introduced.

For instance, when we are driving a car, it’s natural to drift a little side-to-side within our lane. But, instead of large jarring adjustments every minute, we make many frequent little adjustments keeping us centered on the road and therefore moving smoothly around every turn along the way.

Similarly, frequent touch bases are simpler and shorter, and therefore also keep the team in sync moving smoothly through their work.

Now let’s take a look at what a 1 week sprint schedule might look like.

The 1 Weeks Sprint Schedule

Here is what a possible 1 week Sprint Schedule could look like.

Outside of this schedule there still may be additional team meetings such as Project Planning, Project Kickoffs, or Planning Quarter Roadmap.

A week calendar view showing the meetings on each day including standups, grooming, retros, and demos. There are only 6 meetings displayed in total. Standups shown every day at 10am, three of which are longer in length because they include Scope, grooming, and demos. Retro remains it's own meeting.
A sample 1 week Sprint Schedule
Standup (15min) – Everyday at the same time, occasionally bundled with other team meetings.

* Touch base to talk about work in progress
* Update team members of any changes or needs

Week Scope (30min + 15min Standup) – The kickoff for the week.

* Review Previous Sprint metrics, work completed
* Review Previous Sprints remaining stories that will cary over to this weeks sprint.
* Define the weeks big picture focus for the team
* Pull in new stories & Prioritize them
* Pull in/out stories until matches teams throughput (don’t compromise and over commit!)
* Confirm the scope committed to
* End with Standup

Grooming (15min + 15min Standup) – Looking forward to future work and estimating stories

* Start with standup
* Introducing upcoming work & projects
* Breaking down, defining, and estimating stories
* Delegating project leads for spike work

Retro (30min) – How can the team improve

* Depending on how well the team is running this can be every 2 weeks instead of every week.
* Retros should always focus on how the team can improve to become the best team.
* Retros can be sometimes heavy. Therefore Thursdays tend to be best to avoid ending the week with any weight.

Demos! (15min + 15min Standup) – Celebrating the weeks wins!

* Start with Standup
* End the week with great for team morale
* An open form where any team member may share work (in progress or completed) from the week
* Great for knowledge sharing
* Ends the week on a high note.

(expand each section above for a detailed description & structure)

Bundling Team Meetings with Standup

Folks tend to prefer fewer meetings. A clever tool to utilize – combine meetings together that have the same or similar attendees.

In the sample 1 week sprint schedule above, we’ve combined Weekly Scope, Grooming, and Demo meetings with standup. This takes 9 meetings down to 6. Everything is simpler and lighter.

Summary

It’s worthwhile to consider switching your team to 1 Week Sprints. They will give your team more energy and more accurate commitment to their work. 1 Week Sprints will set your team up for even better success.

What does your team use? Would you ever switch?

(cover photo credit: Jonathan Stassen / JStassen Photography)

Coding

Planning Quarter Roadmap for a Team

3 Comments

Planning quarter roadmap and which projects to tackle is daunting.

It’s a lot to think about: What’s most important, What are quick wins, What work needs to be finished, Which stakeholders are most important.

Time to build matters

It’s easy to overlook the size of projects and how long they will take: Requirements are vague, Designs don’t exist, Dependencies are unknown — Everything is guess work.

Including the Team to Discover Scope

It’s tempting to hold tightly what projects are being dreamed of, holding them close until the start of the next quarter — revealing them at a kick off. Keeping the roadmap a secret is dangerous.

Two things this can cause:

  • Surprising the teams that will be building the projects, they have many questions.
  • The time and effort wasn’t decided by the team that will be building the projects, it was likely assumed.

Therefore it’s important to pull in the team to help build out the next Quarters roadmap. It should be clear they likely won’t be making decisions of what gets prioritized. Leveraging the teams to understand the systems that are in place, project managers can work with the team to understand guesstimate time range or amount of effort it might take to accomplish the possible projects project.

  • Better estimates of projects scopes that can inform prioritization.
  • Team is excited for & already understands projects that are in the pipeline

Temptations & Warnings planning quarter roadmap

It can be tempting for a team to dive into the technical implementation of a project. This is ok up to a point, but only to a hypothetical point. The goal is to create a rough range how long it might take.

Time ranges are important. There are always surprises, both good and bad that cause projects to go faster, but typically longer than expected.

When estimating, pick a unit for the time. Let’s say a project may take 2-3 weeks – but is that with 1 person? Or a full 3 person team working on it? It makes a huge difference! When pick units, Stay consistent with those units.

An extended form of hiking in which people carry double the amount of gear they need for half the distance they planned to go in twice the time it should take.

~Author unknown

It’s very tempting to take the low estimate. Don’t use the lower estimate! Projects always tend to run longer for miscellaneous reasons (bugs, scope creep, interruptions, pto, forgotten pieces, testing). It’s much more realistic to pick something in the middle or even the pessimistic estimation. I wrote about a related topic, Why We Estimate Stories which goes further into the cautions of under estimating.

Visualizing the Estimates

I’ve built a spreadsheet layout for looking at projects that have been picked for the roadmap and how they look on a time line.

Again it’s tempting to only look at the Optimistic estimate, and it might be best to delete the Optimistic row if temped by it.

On my teams it’s very important that the entire team focuses and works on only one project at a time (else you really have 2 teams not 1 and projects take longer, gasp!). We also estimated our projects in units of “number of weeks 2 devs working” for each project which makes it super convenient to map out.

I’ve made the Roadmap Planning Template available on Google Docs. Make a copy and give it a try.

Looking at this we can see a lot of great info. For example, we can see something interesting about Project B. It’s 4-7 weeks, the team isn’t very confident in it’s scope & needs. We either need to better define the scope, cut scope, or table it until we better understand it. It puts other smaller projects at risk. Perhaps Project D is high priority to complete in Q4. There are many great conversations we can now have.

Setting Good Commitments & Expectations

There were actually Projects A – J slotted for Q4. That’s 10 projects. Working with the team, even the optimistic projection puts us at the end of Q1, and pragmatically 1/2 into Q2!

If we hadn’t worked with the team to estimate the scope we would have been blind to our commitments we almost made in Q4. While we were excited with hope about all the things we would to accomplish in Q4 we would have been setting ourselves up for failure & disappointment & poor morale. Not only within our team, but also our external stakeholders.

Conclusion

Being pragmatic about commitments planning quarter roadmap is hard but hugely important in setting a team up for success. We are inherently optimistic creatures, we want to promise & hope to accomplish more than is realistically always possible.

Finding tools to help us be honest with ourselves makes us & our teams be honest & better people.

(cover photo credit: Jonathan Stassen / JStassen Photography)

Coding

Why do we estimate stories?

3 Comments

There are two reasons we estimate stories: to understand scope and then to communicate that size of that scope to others.

Understanding Scope of Tasks

In order to be effective at anything we do in life, it’s best to step back and understand what it is exactly that we want to accomplish.

  • How hard is it?
  • How complex is it?
  • Are there unknowns?
  • How long might it take?
  • How well do we understand it?
  • Are there other tasks that need to be done first?

As an individual we ponder these questions ourselves. As a team we discuss them together during our weekly scope and grooming to refine our shared understanding.

It’s easy to dismiss small tasks as not worth any further scrutiny because they feel obvious. Asking these questions takes little time. Even the simplest tasks can hold surprises if we take a moment to ask these few simple questions.

A fool does not care whether he understands a thing or not…

– Proverbs

Communicating Effort

It’s hard to express how long or hard a task is to others that are not in our domain of knowledge. Perhaps they’ve never seen what code even looks like, much less tried to program.

Thus we point and estimate stories. I prefer to call them effort points or “oof” points. How much “oof” effort does something take to accomplish.

Here is an example with my household chores.

“oof” effortStory Points~Time
Take out trashLittle “oof”11-10 min
Wash the dishesSmall “oof”310-60 min
Mow the lawnMedium “oof”51-3 hrs
File taxesBig “oof”83-8 hrs
Remodel bedroomLarge “oof”132-5 days

What’s important to notice is that Story Points / Effort doesn’t mean a specific length of time but rather an estimated time rage.

Story Points are a valuable tool to roughly translate effort → time estimations.

This gives Project Managers a way of estimating a rough expectations of when a collection of tasks might be completed. This empowers Project Managers therefor to set a realistic estimated timelines & expectations with external stakeholders for when tasks and projects might be completed. I wrote more on Planning Roadmaps & Project Estimation in another post.

Personal Cautions & Notes – Estimate Stories

  • Lean heavily on higher end time values when trying to translate points to time; that is be pragmatic.
    • It’s highly unrealistic it only takes under 1 min to take out the trash & put a new bag in, probably closer to 8 min.
  • Project managers don’t mind hearing that something is complex, big or unknown, the sooner they know this the better.
  • Project Managers love the radical honesty, it helps them set realistic expectations with their stakeholders.
  • Always round up to higher point levels if something is on the fence.
  • Talk about estimating with your team and create a good Developer Culture when you estimate stories.

(cover photo credit: Jonathan Stassen / JStassen Photography)