1

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 !

Improve this question
2
  • 1
    If the tasks discussed are so complex they deserve a pencil-and-paper scetch of the design to make a sensible decision about the poker points, then you should discuss the issue with the team (and not with some strangers from the internet). Maybe others of the team feel similar and want some extra preparation time beforehand, or it turns out the idea is to stop team members from investing three hours of planning into a one hour task. – Doc Brown Oct 2 '17 at 19:22
  • 2
    Is there a whiteboard in the room? My team used to collectively design on the whiteboard during our planning meeting. – RubberDuck Oct 3 '17 at 9:44
5

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.

Improve this answer
4
  • 1
    Indeed, the whole point of frequent iterations and tight feedback loops is that a) problems get smaller (you only estimate 3 weeks worth of work, not 3 years), b) you get more practice (you do estimations every 3 weeks instead of every 3 years), and c) your mistakes are corrected immediately so that you can learn from them (you know after 3 weeks whether and by how much you have over-/underestimated). – Jörg W Mittag Oct 1 '17 at 19:00
  • 2
    Yep, I've worked month long, 3 week, 2 week, and 1 week sprints. I prefer 1 week because the loops are tight and the meetings, while more frequent, take less time. And I spend less time lost in the weeds. – candied_orange Oct 1 '17 at 19:05
  • That's the idea behind the "Extreme" part of "Extreme Programming". If something is a good idea, do it extremely often and extremely early. (E.g. code review, testing, releasing.) If something is hard, make it extremely small and practice it extremely often. (E.g. integration, building, planning.) – Jörg W Mittag Oct 1 '17 at 19:20
  • Also, after a month you probably don't have a deep understanding of the project as a whole. You probably understand the basic flow and structure but don't have an intuition about how to integrate something new yet. As time goes on you will start to better see/know where some new functionalities will go and what will need to be done to integrate them. Someone with 2 years experience on your project literally has 24 times as much experience with it as you do right now after a month. – Hangman4358 Oct 2 '17 at 14:07
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.

Improve this answer
1

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.

Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.