How can I quickly visualize software in meetings?

Question

I have started a new job as a software engineer one month ago working on a web, saas oriented piece of software.

I like it, but I have spotted an area where I need to increase my skills, which is visualising new features of software in my head, fast.

Let me explain the context: we are a small team of 6 developers, we work in an agile environment, with sprints of 3 weeks.

At the beginning of each sprint, we meet for a poker planning session. The goal of the meeting is to discuss the difficulty of each task of the following sprint, in order to validate that we are able to implement all of the tasks in 3 weeks.

To be able to discuss and evaluate, I have to imagine how the new features will be designed, how they will integrate the existing systems etc.

It is hard for me because in my previous job, I always used a pen and a paper to design. Plus, I had time to do it before going to meeting, not in "real-time". Now I have to do it in my head, as we speak and I find it is hard to connect all the dots.

Do you know how can I improve this skill ? Thank you guys !

Answer 1

You get better at this by repeatedly doing this.

I've done this for years now and no one is perfect at it. The whole point of "team velocity" is to admit and track how bad we are at it.

Team velocity tracks how much real time it takes the team to get through estimated time. You should pay attention to this and learn.

Even with years of experience you'll still get surprised but in time you'll have a better feel. That means when it turns out your estimates are wrong you'll spot it and report it sooner.

As for poker points those have their own exchange rate from team to team. Just use them to express how you feel about a story. I do it mostly by counting the number of things I'm going to have to do for the first time ever.

And remember, this isn't design. This is just planning.

Answer 2

As CandiedOrange states, the ability to quickly "see" the shape of a design approach is something that comes with experience (and obviously varies with the complexity of the requirement).

However, the real answer is this shouldn't be the first time you are hearing of these stories. There's a process in Scrum commonly referred to as "Backlog Grooming" (called "Product Backlog refinement" in the Scrum guide) that should be occurring. Basically, developers should be spending some time looking at and clarifying user stories that are in the Product Backlog that aren't yet in the current sprint. This could be on an individual basis or there may be regularly scheduled meetings to do it or meetings may be scheduled "on-demand" if a particular story. There are other ways of arranging it; do what makes sense for your team.

Even if you don't look at user stories outside of the Sprint Planning meeting, you should still be maintaining at least a couple sprints worth of work that is estimated, refined, priority ordered, and ready to go. You should not be estimating just enough of the Product Backlog for the sprint that's about to start. For example, if a sprint is going well, you should be able to pick up stories from the top of the Product Backlog and move them into the sprint without needing to do a mini-planning (though adding a story to the sprint should still be something the team agrees to as a whole in a Daily Stand-up meeting, say). You should also reestimate stories (if anyone on the team feels it worthwhile on a story-by-story basis) just before they are added to the sprint in case someone has learned something new that might impact the estimate. You aren't beholden to any estimate made before a story is added to the current sprint. With even this minimal approach to backlog grooming, you'll get at least two cracks at estimating most stories and at least a sprint's worth of time to think about them before they get accepted into a sprint. (Of course, the "thinking about them" is exactly backlog grooming.)

Given that minimal approach, you still have the problem you are describing of needing to quickly estimate a story cold, but now your initial estimates are much less critical. Having multiple sprints worth of stories estimated, even with estimates that may change, allows other stakeholders and particularly the Product Owner to get an idea of when (and if) stories will be delivered and what the impact of inserting new, high priority stories is.

Answer 3

There are different strategies for estimating, and it's important to understand the rationale behind.

The approach that you've used in your previous job seems to be a bottom-up approach : you sketch some design with paper and pen, then estimate the different pieces that you've identified, and finally add these estimates together:

• your ability to estimate will depend very heavily on your understanding of the detailed design.
• you need to do this extensive analyse before it's even decided if the story will be taken on board or not.
• significant difference in the real design (e.g. some missing pieces) will make your estimations totally wrong, jeopardizing the sprint's objective.
• you get caught yourself in your own design, that you made solo without the benefit of the team's power. Isn't this a kind of mini-waterfall approach ?

The planning poker uses a different approach. It works by analogy, by comparing the story to similar stories, or a combination of them:

• If you estimate by analogy in solo, you can tap only into your own experience.
• The team however has the much more diverse experience of all the members together. This helps to better identify similarity with previous stories some team members has worked on in the past.
• If estimates of the team members are too divergent, the discussion process will help to reach a consensus, everybody revising their judgement, taking into account some facts that he/she was not aware of. This is why this technique has proven to be so effective.

The planning poker is also a learning tool: at each sprint, you have new estimates, that you can compare with the achievements. The retrospective allows you then to understand the estimation bias and improve the abilities in this matter.

Answer 4

Consider having fairly brief one-on-one conversations with colleagues the day before the planning meeting, to prepare for it. Use pen and paper during such conversations, and refer to your notes the following day.

During the planning meeting, instead of planning / communicating with pen and paper, use a whiteboard. Invite others to embellish your architectural diagram or notes on needed data field names. The six of you can come to shared consensus with words you all hear, but also with a diagram that you all can see. After one or two meetings, decide which approach achieves consensus faster.