One of the most common questions discussed among the Agile Community is what should be done when a team doesn’t finish a user story (US) in a sprint? How can people track the progress made on an incomplete user story? In this blog post, I’ll share our approach to this question.
According to the community, when a developer finishes their work in the last few hours of an iteration, they must try to help their teammates finish their work. Otherwise, it’s recommended they help prepare the next cycle of work, analyzing the next user stories, refactoring a piece of code that could be better implemented, or writing tests. It is not advisable for a developer to get a new user story started if they won’t be able to finish this in the same cycle. However, this first approach is not always possible because user stories can be underestimated or something can happen that would delay the delivery of the user story.
A second alternative is to split the user story into two smaller ones and develop the one that can be finished on time. The first user story’s points are credited in the current cycle, the second one’s are credited in the next cycle. This approach improves the visibility of what was done in the current cycle. However, it hurts the agile philosophy, in some way it would be a delivery without business value for the customer.
The third way is for the unfinished user story to go to the next cycle with the original estimate. When it gets completed, the user story’s full effort estimate gets credited to the velocity of the new iteration. This could skew the average velocity metric, so be careful, because this is important to the Product Owner (PO) for forecasting and planning. Also beware to not have a bunch of backlog items almost done: one user story delivered has more value than a lot of user stories 90% complete.
How do we do it?
Usually, we use the first and third approaches in the following way:
- We try to concentrate efforts on work that is closest to delivery. As soon as a developer finishes the first US, they will verify if someone needs help with finishing a task or if some user story in the current cycle has defects that need to be fixed. Keeping the work-in-progress as low as possible helps to focus on what matters most. This process is repeated until the end.
- If this list is empty and the cycle is almost over, the developer looks for the smallest or most valuable user story (depending of project’s context) to be done.
- If the user story has not been finished by the end of the cycle, this US shifts to the next cycle with the original estimate. However, when we plan the next cycle, we’ll consider just the missing points to finish the US.
- When this US gets finished, we credit the whole user story’s estimate in our velocity.
- If the developer after resuming the work on the US in the next iteration realizes that the user story was overestimated or underestimated, usually, we don’t change the estimate on the story itself, but we update our ruler score with the real estimate, as lesson learned.
Note that we do not use these exact steps every single time, everything depends and adapts according to the context of the project or the moment. The most important thing is you prioritizing to deliver maximum business value to the customer.
And you? What do you do when you have an unfinished user story in your cycle? Share with us yours experiences!
Last month our team went to Agile Trends, an event in São Paulo where discussions revolved mainly around Agility in software projects.
Starting the event activities, Niels Pflaeging presented a keynote where he defends Agile alone is not sufficient to taking organizations to the Knowledge Era, and that deeper transformations are necessary for doing that. He started it with an overview of the History of Management, why bigger companies are structured the way we know them and what he believes needs to change so they can adapt to the new reality and remain competitive.
After the keynote, the so-called “Trend talks” started. Each Trend Talk session was composed of two 18min talks revolving the same theme, followed by a 20min discussion round. In the Trend talks, most of what was presented and discussed was related to the challenges companies face when adopting agile.
During such presentations, most of the success cases presented how companies have adopted the Agile principles but adapted the practices to their own realities, be it a startup or a bigger corporation. Which is similar to what we’ve been doing in our own projects: whenever we start a new engagement we use our custom methodology as a Starting Point and, as we get to know more about our clients, we adapt it to better suit their realities.
Other presentations also showcased some of the Change Management challenges that companies have to face in order to make this work. These topics are similar to our own challenges when engaging client projects, and it was interesting hearing the struggles from other professionals so we can make sure to always keep our toolbox up to date.
The event also contemplated some workshops, and we joined one that had Kanban as its theme. In this workshop, we honed our skills while running an imaginary pizza place (too bad the pizzas weren’t real) and as we progressed in the game, we could also buy adjustments to our workflow in an “upgrade store” using the cash we made. The point was to get us thinking about how our decisions affected the business’ performance and profitability. Besides that, we also joined a workshop about Learning 3.0, where the participants were divided in small groups and each group had a real problem to work on. We had to understand, share experiences related to the problem and discuss ideas about how to solve it. In this workshop we had the opportunity to work with people from other companies with different backgrounds, which contributed to bringing different perspectives to the discussions.
Finally, we also attended some interesting Keynotes addressing themes that were not directly related to Agile, such as Internet Privacy and the Internet of Things. Even though not directly related to project management methodologies, they were nice in the sense they help us keep our minds open to other trends related to the tech landscape.
Being part of the event was a great opportunity to see how events related to Agile have gained increased traction during the past couple of years. It was also nice meeting old friends there, as well as meet new people.
Have you also been to Agile Trends? Did any of the talks catch your attention in special? Please let us know it in the comments.
Dave Thomas wrote a blog post called “Agile is dead (Long live agility)“. In the blog post, he claims the use of “do Agile right” as a way to profit, whereas it should make people – developers specially – to deliver valuable software more effectively.
It had a huge impact in the community in a way that many other people came up to point out their opinions. Also, some good texts about the subject came up as Andrew Binstock’s “The Corruption of Agile” and Allen Hollub’s “The Agile Holocracy“. In reply to the last two articles, Uncle Bob wrote “The True Corruption of Agile“. These are the kind of movement that make the industry to evolve: to criticize the “state of the art” practices and ideas. And to better understand what’s going on, it is better to step back and look for what “Agile” is supposed to mean. Watching a talk by Martin Fowler and Neil Ford called “Explaining Agile” can help us to better understand it. I’ll try to tr;dl the talk by Martin and Neil, so we can follow along with the discussion.
Before the whole Agile idea had emerged, industry majority used to follow waterfall by using frameworks and methodologies that support its idea, such as ISO 12207 and CMMI. All of them established a strict set of practices that should be followed in order to be compliant. The practices became a process and each person would take an input and then transform it into an output which would be someone’s else input.
And so did the tools, they were designed to support the same process for every company. Everything should be automated in such way that development pipeline (requirements, design, development, test, maintenance) would work perfectly. The only team with autonomy to change the process was the process quality team.
A successful project in waterfall would be one where everything run as planned. All people did was following the plan and making an input into an output hoping to get the final product at the end of the project.
It was noticed that the plan needed to be changed often during the course of the development and the later changes were needed the more expensive they would be. Although there are certainly exceptions, it’s usually very hard to plan a project and not needing to change it.
It would be better if the plan period was shorter and, by making it shorter, one could adjust the plan between periods. In order to make a good plan, review and retrospective meetings came up, so it would be easier to spot problems and to solve them. And to do so, it is necessary to give the autonomy to the team to change its own process independently of its project or organization unit.
That’s why “Agile” came for. We would have iterations and after each one we would have a chance to change the course of the project, to change the way software is being developed and to change the whole plan, so that we would have an empirical process/practices and not a strict defined process.
Where the corruption is
All the discussions raised by the cited articles are being fired by the same reason: “agile” is being misused. People are creating strict practices and process and taking it as “the right way” of developing software, whereas they should consider the empirical knowledge that each project gives as feedback.
It is needed to adjust the process and practices in a way it makes sense and turn the software development easier to maintain and faster to deliver value. In order to accomplish that, you have to change things. Embrace the change was not supposed to embrace only the requirements change, but any change.
People has turned Agile into a set of strict practices, when it is a philosophy/culture of how to react to environment stimuli. The practices are the reflex of the reaction and, biologically speaking – don’t forget software is built by living beings -, people can react differently for the same stimulus. And in this thought is where people is corrupting the agile.
I’ll give a real example to try to make myself clearer. When you work on different projects with different clients, the cultural differences among the stakeholders are more evident. So, it is our job to make the project to succeed and the way of doing that is adjusting the process over the time and don’t be afraid of doing new things.
For instance, I worked in a project once that was following Scrum guidelines. At some point, the plannings were not taking even a full hour. The stories were well defined: PO and the Scrum Master already had prioritized them before the planning had began. We used to estimate them before the meeting and the only discussions raised during the planning were about making sure developers had understood PO’s needs.
Because of that, in some retrospective meeting we decided to merge Kanban with Scrum and have something hybrid. We would still estimate the stories so we could keep the predictability, but we did not had plannings anymore. Bugs and User Stories were prioritized in the proper column and the developer would assign himself to the most prioritized one. Plan changes were notified by Campfire. When a doubt about the US was raised, Scrum Master and the assigned developer would talk directly with the PO using Google Hangouts and/or Campfire. The changes were communicated to the others developers through Pull Requests.
We got autonomy to change things and it was very satisfying to see the results. Always remember those left-sided values from the agile manifesto and let it flow. Remember that the process cannot decide how you work, but the other way around. We had delivered with agility, even though we took the risk of going out of the box and not being tied to the conventional practices.
Finally, I want to thank everyone who is helping to push the community forward by raising discussions like that. As always, when discussing, be aware that we criticize the practices themselves, not people or companies. There is no such thing as “right” or “wrong” for subjects like this, there is what works and what works better for you. So, what other practices can we discuss about? Have you done any change which had a huge impact? Share with us on the comments below.
The formal definition of estimate is “an approximate judgment or calculation of the value, amount, time or size of something”. In a software development project, estimates are important to help us predict how much time will be necessary in order to finish a set of activities, or to select and prioritize scope for a release or iteration.
It’s rather common on Agile projects that the estimates are done in a planning poker session. Each team member has a deck of cards with the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13), and for each user story (US), the team member privately selects one card to represent his or her estimate. All cards are then revealed at the same time. The estimates can represent story points, ideal days, or other units of cost that make sense to the project. Usually we use story points because we can consider three different aspects when estimating: complexity, effort, and risks. The story point unit allows us to more effectively capture sources of variation compared to an hour-based estimate.
Since story points are a relative measurement unit, the first step your team should take is to define one story as the baseline, so that they can estimate the other stories comparing to that reference. According to the literature, the team should find the simplest story in the backlog, and assign 1 story point to it, after that, they use that story as baseline to estimate the other stories.
However, here at Plataformatec we go a step further on defining that baseline story. We select at least one user story for each story point that we use, composing a “ruler score”.
In each sprint, we update the stories in the ruler with US’s of the previous sprint, so that when our team meets for the planning poker session, they have at least one baseline story on each story point to compare to.
Using that practice has brought us a lot of benefits, such as:
- The estimation process is more effective because the reference to each story point is clear, reducing the length of the discussion among the team;
- Even if the team has a new member, the story point variation is reduced because this practice enforces a reference to each story point in the “ruler score”;
- The team members have the same reference for each story point, preventing someone from having an implicit story point reference that is not shared among the others;
- On each sprint, the estimates becomes more and more stable, since using the ruler score guarantees that the story point references are always updated.
That’s it! We’d like to know what are your practices in estimating using story points. And if you try out the ruler score, let us know your results!
O Agile Tour, considerado o maior evento sobre agilidade do mundo, tem como objetivo disseminar a visão, a cultura e as práticas adotadas pela comunidade ágil no desenvolvimento de software através da troca de experiências entre os participante. É uma excelente oportunidade de aprender mais sobre as nuanças do ágil no dia-a-dia dos profissionais.
Ano passado, em sua terceira edição, o Agile Tour reuniu cerca de 7.500 participantes em 44 cidades espalhadas por 15 países. No Brasil, o evento foi organizado em 5 cidades e atraiu mais de 600 pessoas no total. Esse ano, só no Brasil serão 12 cidades participantes e, com certeza, teremos um recorde no número de inscritos.
Ao longo do dia teremos nove palestras sobre diferentes temas – dentre os quais: “PO, tão simples como dizem?”, onde estarei representando a PlataformaTec em um bate-papo com o público sobre os skills do Product Owner que nem sempre estão presentes nos projetos ágeis.
Caso você se interesse pelo assunto, não perca o Agile Tour 2011. Além de ser uma maneira diferente de se aprender mais sobre ágil, é um ótimo canal para conhecer pessoas e ampliar sua rede de contatos.
Ah, o evento é gratuito! Por isso, não perca tempo e se inscreva já!!
*This blog post tells about how we improved a VCS workflow to another one that suited our and the consumer needs. It was a great result: we minimized the chances of occurring one of the worst problems for a developer in a project: big integration while we maintained an ‘almost releasable branch’ all the time
In the last months we’ve been working on a project with a mixed development team (Plataformatec’s team and the customer’s team). We, of course, used a version control system (specifically git) and we set up a nice git branching model for our team. As agilists, we know that we should not use anything that requires a lot of bureaucracy (things like opening a ticket to integrate a branch into the trunk).
Using nvie guide as base, we developed a git workflow. First of all, we had three main branches:
- production: contains the code that is currently on production. We also have a production server that contains, obviously, the production code up and running.
- staging: contains the code that is being tested before going to production (we used this branch to deploy to a production-like environment that worked as a final test until production, this environment is also called staging)
- master: contains the already accepted features. To consider a feature as “accepted” we deployed to another environment (called “dev”) and asked a QA analyst to test it. Once approved we merged the commits. This “dev” environment is used for this kind of approval and also for general purposes like when we say: “take a look at this new awesome feature we’re developing”.
For each feature that we developed, we created a git branch (almost all of them we pushed it to the remote server to facilitate code review and to deploy to the “dev” environment). Everyday, we ran
git rebase master, to update our branch code (except for features developed by more than one developer). Once the feature is complete, we rebased master into it, and merge it using –no-ff (to create a merge commit). For the branches that more than one developer worked on, we usually talked and set up a “rebase period” where one does the rebase, forces the push (because you changed your local tree so git does not accept it as a non forced push) and updates the remote branch.
Close to the production deploy, we merged (always using –no-ff) master branch into staging branch and deploy to staging. Once approved, we merged to production, and created a tag telling the current version of the application and then we do the deploy. When we deployed to production we also removed the merged branches from the remote repository.
One of the great advantages of this schema is: Master is always “almost” ready for a release. Yeah, some features really deserves to be validated right before the deploy, because another feature can break them, but we kept the master as an “always releasable stable” branch (and also we used a continuous integration tool in order to enforce all tests passing). Another great advantage is: as we updated our code everyday, it was very unusual for us to face big integration scenarios.
For the “dev” environment deploy we also set up a capistrano task that asks which branch we want to deploy to be possible to deploy something from any branch.
This workflow has worked really well for us and maybe it is useful to you (maybe for you to adapt it to something that works better for you as we did with the workflow suggested on nvie).
To summarize, this is our git workflow in commands (supposing that we are on master branch):
git checkout -b my-awesome-feature
# (... you do some code and some commits and you go home to have some sleep or maybe play some starcraft 2 ...)
#(arrived at the office on the next day)
git rebase master
#(... continue working and commiting and sleeping (or maybe playing some starcraft 2 ...)
git rebase master
# (... some commits ... and voila ... you've finished...)
git push origin my-awesome-feature
cap dev deploy
# (...YAY! QA analyst just approved it ...)
git pull origin master
git rebase master
# (run the tests to ensure all of them pass)
git checkout master
git pull --rebase origin master
git merge --no-ff my-awesome-branch
git push origin master
#(... it is time to validate on staging)
git checkout staging
git pull origin staging
git merge --no-ff master
git push origin staging
cap staging deploy
#(... QA analysts validate the staging ...)
git checkout production
git merge --no-ff staging
git tag -a v1.4.2 -m "Releasing on 13th February"
git push origin production
git push --tags origin production
cap production deploy
Well, this is how we improved a git workflow based in another one. As almost everything, there is no bullet proof for it, but we found interesting to share this experience with you as it was a success (every developer on the team enjoyed it). But please, we would like to receive some feedback about it :-). Have you used something similar in your team? Do you have any ideas on how we can improve it?