Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > 2015 > March
2015
If you are a member of the Alfresco Development ecosystem or you attended one of the recent Alfresco events, you might have heard of the Release Agility project, a major investment we are doing at Alfresco to improve the pace, quality and modularity of our development and release process.



And if you monitored the Alfresco Public SVN and/or you build Alfresco from sources, you might have noticed some substantial changes in our source code layout, specifically related to the Share webapp location.



In case you were guessing, yes, these two items are tightly connected and in fact the changes in SVN changes are just one of the initial steps of the larger process improvements driven by the Release Agility project.



So, in the spirit of open communication and in pure Sinek-ian fashion, let me give you a general idea of the changes, starting with why we are doing this.







Why



One of our company goals is to be more agile when it comes to releasing our products, like the Repository, Share and other modules composing the Alfresco Portfolio.



In Share, for example, we’d like to be able to deliver enhancements out to market more frequently than we currently do and allow customers to consume those without needing to upgrade their core Repository.



Upgrading the whole system can also be a large project in itself and requires lots of testing and occasionally re-development of customizations. Allowing the repository and Share to be upgraded independently could prevent significant costs and allow users to get new UI features faster.



To allow this to happen we need to de-couple the repository and Share, and the first step is separating the code and build process. The code used to build Share has therefore moved and we adapted the build system and development environment.



This should immediately benefit both repository and Share developers as there is less code to checkout, less code to build and allows them to focus on the area they are developing using a small self-contained standards based development environment.



The Release Agility project will be an on-going project and more code will likely be moving to separate code-bases, in a continuous strive to become more modular and agile in our development and release process.



What



The Share Webapp code has now moved to the following locations:


You can track progress of the Release Agility project in Jira and reach out to me for feedback.



How



In order to build the Share webapp, from the http://svn.alfresco.com/repos/alfresco-open-mirror/web-apps/Share/trunk/, run a standard



mvn clean install





to produce a Share WAR file that can be manually deployed to a Tomcat instance.



You can also import the project in every modern IDE natively compatible with Maven (e.g. Eclipse Luna or IDEA).



Next steps



We will keep you informed as more of these changes occur, in the meanwhile make sure you update your checkout often.



Stay tuned, as we are working to make development on Alfresco an even more amazing experience!



P.S.: In case you were wondering, kudos and trademark for the Agile Gibbon (tm) go to our Chief Architect Dave Caruana, who is playing a key role in the Release Agility project!



Introduction

It was recently announced that Alfresco 5.0.d has been released. There is lots of great stuff in this release for the Alfresco Community to enjoy - but the thing that I'm most excited about is that 5.0.d has a dependency on artefacts created from the independent Aikau GitHub project. This is a significant change because, for the first time, it is going to allow Community users to have access to the latest UI updates and fixes, rather than needing to wait until the next Community release.

 

The Benefits of an Independent Aikau

Before I explain how unbelievably easy it is to upgrade the version of Aikau that is used in 5.0.d, let's cover some of the reasons why you should be excited about this change if you customize or make enhancements to Alfresco Share.

 

First and foremost, you can get an updated version of Aikau every week - this means you get access to the latest widgets, improvements and bug fixes almost as soon as they are implemented. Those enhancements can even come directly from the Alfresco Community as we're very happy to merge your pull requests into Aikau, if they meet our documented acceptance criteria.

 

This means that you don't have to passively wait anywhere between 6 months and a year for a new release that may or may not contain a fix that you might be hoping for. Now you have the opportunity to raise bugs (and optionally provide the fixes for them) as well as raising feature requests for inclusion in future development sprints. This gives the Alfresco Community unprecedented influence on updates to the UI code.

 

The Aikau project backlog is public so you can see what we're going to be working on in the near future, and can give us an indication of what you'd like to see implemented, by raising new issues or voting on specific issues.

 

How to update Aikau in 5.0.d

The best part is that you won't even need to re-build anything in order to get updated versions of Aikau... you just need to follow these 3 simple steps:

 

    1. Download the JAR for the version you want from the Alfresco Maven repository
    2. Drop it into the 'share/WEB-INF/lib' directory
    3. Restart your server.

 

That's it.

 

No really, that's it... Surf supports multiple versions of Aikau and will always use the latest version available (although you can still manually configure the version used with the Module Deployment page if you want to).

 

The Aikau project even provides a Grunt task called 'clientPatch' for patching Aikau clients, if you've cloned the GitHub repository and want to verify your own changes before submitting a pull request. You can even configure a list of different clients and then pick which one you want to update.

 

Summary

With the release of 5.0.d you can now take advantage of the latest updates to Aikau as they happen. Your installation of Alfresco Community can keep up with UI related bug fixes and your customizations can leverage all the new features and widgets that get released every week.

 

Alfresco Community 5.0.d is a great release and is going to revolutionize Share UI development.

 

 

 

 

 

 

 

 

Story Points?

Posted by tbagnall Employee Mar 20, 2015

by Tristan Bagnall



Recently I have been asked quite a bit about story points here are some of the answers I have given.

To give some context and scope around this post, here are some quick facts I have learnt about story points:

    • For story points we use an altered fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, 40 ,100. (Some tools use 20 instead of 21)
    • Story points are abstracted from elapsed or ideal time.
    • They are like buckets of accuracy / vagueness.
    • The larger they are the more assumptions they contain, the larger the probable complexity and therefore effort.
    • They are numbers, allowing the use of an empirical forecast
    • They are used by the Product Owner and enable them to do forecasting - the PO should find themselves being asked, when will I be able to have a usable checkout (or other feature).
    • They are used on user stories a.k.a. product backlog items (PBI)
      • Epics are included as user stories, even though some tools have adopted a taxonomy that suggests Epics are different to user stories.
      • They show the relative effort and complexity of a chunk of work.
        • They are a vector - 8 story points is 4 times as much effort as 2 story points (4 x 2 = 8)

       

      There is plenty of literature out there about story point, estimation, etc. This is not meant to be exhaustive, but I would encourage everyone to read about them.

      Why not use man days instead?

      Everyone has an opinion on what a man day is - it is kind of mythical as it means so many things to different people.

      Man days suggest that there is little complexity and we are certain on what needs doing - after all days can be divided into hours (24ths) so they are very accurate.

      Man days also start give an expectation of a delivery date, even if they are padded out by saying they are ideal man days. However once you start with ideal man  days you then get into confusing realms of what is ideal and what is really happening. For example:

       

      • 1 man day, might be 2 ideal man days as the person is only spending 50% of their time on a team (a 50:50 split).
      • But in reality they are context switching every 30 minutes, so the time split is really less than 50% - context switching is very expensive and leads to poor quality work. So the real split might be something like 40:40:20.
      • This suggests that 5 man days are really 2 ideal man days.
      • At this point normally a large debate starts, with boasts about how easily someone can context switch and these (or any) figures are wrong.
      • At the end of the debate there is a lack of clarity and therefore the man days have become meaningless


          It is generally accepted that it is better to work out the effort and then measure how a team progresses through that effort.

          Why the sequence of numbers?

          As we continue to have conversations about an item of work we get to know more about it, we therefore learn about its complexity, we remove uncertainty and get an idea of the effort involved to deliver it. While we do this we break the work down into more manageable parts. Through all this we are testing assumptions, either removing them, or correcting them or validating them.

          As we gather all these moving parts we can become more accurate about how much effort is needed. While it is big, we have a lot of assumptions, and due to that we are pretty vague.

          So how does this tie back to the sequence of numbers?

          As we can be more accurate with the smaller items we need more buckets that are closer together to put the chunks of work into. Therefore the first part of the sequence is ideal: 1, 2, 3, 5, 8.

          Then we have the large chunks with lots of assumptions - the epics - that need to be broken down before we can work on them: 40, 100

          Then we have chunks that we have become more familiar with, partially broken down, but are still too big: 13, 21.

          How small should a user story be before I start working on it?

          Another way of putting the question is

          • how much uncertainty should remain;
          • how many assumptions should be cleared up;
          • how effort should there be;
          • can it be finished in the sprint - meeting the Definition of Done?

          before I pull a user story into a sprint or into progress on a kanban board?

          This depends on several factors:

          • How much uncertainty are you comfortable with?
          • How will the remaining assumptions affect your ability to deliver the chunk of work?
          • What is the mix of the sizes you are pulling into a sprint?

             

            As with all things agile there are exceptions and generalisations. One observation I have made is that many teams think that they can take large chunks of work into a sprint, however this means there are lots of assumptions still to be worked out, lots of vagueness and uncertainty. This leads to a lack of predictability and consistency on the sprint delivering.

             

            Therefore I have normally advised the largest single chunk going into a sprint is 8 story points, but there should always be a mix of sizes going into a sprint.

            by Tristan Bagnall

             

             

             

            Not sure how to start sizing stories?

             

             

             

            A clever agilist once showed me a really useful technique to help teams start with story points and break the initial barrier on estimating. Here it is with my twist:

             

             

            Pick a story that you think is small, perhaps even the smallest on the wall -

            • well understood,
            • not many assumptions,
            • understood by all the team,
            • little effort to get done

             

                1. Find all the similar size stories and label them all as small
                2. Look for the next significant size up and label them medium
                3. Look for the largest stories and label them large
                4. Now go back to the small stories
                5. Mark all the small stores on a scale of small, medium and large, Try to think of the medium as about twice as large as the small and the large as about three times as large as the small.
                6. Move on to the medium sized stories and mark them all as small, medium and large
                7. Move to the large stories and mark them as small, medium and large. Try to think of the medium being half (or less) the size of the large.

               

              You should now have user stories labelled and  marked:

              • Small - Small
              • Small - Medium
              • Small - Large
              • Medium - Small
              • Medium - Medium
              • Medium - Large
              • Large - Small
              • Large - Medium
              • Large - Large

              We can use these to translate to story points:

               

              SmallMediumLarge
              Small123
              Medium5813
              Large20 or 21*40100

               

              * Depending on your tool you may find support for 20 or 21

              by Christine Thompson



              Self-directed, cross-functional teams



              Here’s one of the things that I love about Scrum. Scrum is a simple system which allows people to be intelligent within it. It assumes that team members do the best they can within the constraints of the system they work within. If something goes wrong, it is generally assumed that it is the process that is at fault and not the people. The Carrot & Stick approach doesn’t motivate people in skilled work.  Instead, autonomy, mastery and purpose do.



              Scrum teams should be self-managed, self-organized and cross-functional. Team members take their direction from the work to be done and not from the Scrum Master or stakeholders. To empower the team, they need authority, resources and information. Scrum itself values team success over individual performance.



              Each scrum team should be made up of team members with cross-functional, “T-shaped” skills. Whilst people may have an area of speciality, they also have a set of broader skills which overlap with those of their team-mates. If a skill-set is over-stretched, then other people need to step in and fill it. If a skill-set is missing, then we need to train people up.



              Finally, reforming teams frequently is wasteful as it takes a long time to establish a performant team.



              Powerless teams



              So what are the characteristics of a powerless team? They may be heavily directed by the Scrum Master and/or influenced by people outside of the team. They’re not making their own decisions, they’re being told what to do. Perhaps they get no value from the daily stand-up: they address the Scrum Master and use it as a status update. Individuals either don’t participate or they argue about everything. People work in isolation and just “do their own thing”. Communication happens indirectly, via comments in tools instead of face-to-face.



              Empowered teams



              So what does an empowered team look like? The team share an understanding of their tasks and what it takes to complete them and they find their own answers without having to revert to other authorities. Individuals offer to help each other out whenever and wherever they can. The team values its interactions and conversations; all the meetings they hold are considered of value. Everyone shows respect to everyone else, everyone in the team is valued equally and the whole team works towards completing their goals together.



              Role of the Scrum Master



              So what’s the role of the Scrum Master in empowering the team? The Scrum Master is not the same as a Team Leader or Tech Lead. They are a “Servant leader” – they facilitate but do not manage the team. They may question and challenge things but they have no authority because the team manages themselves. It’s important that the Scrum Master sets the tone of the team in their own behaviours and they also provide the social grease on the distributed team, encouraging teams to use the thickest form of communication available at any time.



              For example, the Scrum Master disempowers the team when they:



              • Assign or ear-mark tasks for individuals - team members should decide what they will progress next themselves, based on the information they are given in the scrum meetings and from their understanding of the sprint backlog


              • Influence the sizing of tasks - unless they are performing a dual role as an engineer on the team, the Scrum Master does not take part in, or steer the outcome from, the sizing discussions


              • Make design / implementation decisions for the team - again, unless they are also an engineer on the team, the team members themselves should be making decisions about how a task will be implemented


              • Interfere with the flow of the sprint - if the the team has all the information it needs about the priorities and tasks in the sprint, then there is no need for the Scrum Master to influence people on what tasks they should be working on and when


              • Chase progress instead of chasing blockers - the Scrum Master is there to facilitate and not to manage the team. Asking for progress updates does not engender trust between themself and the team. Such information should be available from the task board and the Scrum Master should only be chasing impediments.



              Instead, some examples of what the Scrum Master might do to empower the team:



              • Reduce / eliminate “command and control' practices so that teams can run their own sessions openly and honestly; ensure that dysfunctional meeting participants are controlled


              • Ensure that barriers between team members are removed


              • Work with the team to remove impediments effectively


              • Protect the team from stressful outside influences and unnecessary interruptions


              • Prove a level of true commitment to the team - teams will not feel truly empowered until they see that the Scrum Master is serious about the role



              Final thought



              The ultimate goal of the Scrum Master is to coach and support the team to the point at which is becomes truly self-organising, autonomous and empowered. In the words of Nanny McPhee: “There is something you should understand about the way I work. When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go. It’s rather sad, really, but there it is.”
              cthompson2

              ScrumBan

              Posted by cthompson2 Employee Mar 18, 2015
              by Christine Thompson



              Why ScrumBan?



              I first started looking into ScrumBan when I was working with a team who had been doing a prolonged period of feature development and had a well-established Scrum process. Everything was working well for us until we started to transition into a phase of bug fixing and support. Suddenly we found that we had too much support to have predictable sprints. We could never finish a sprint because the support tasks couldn’t be sized accurately. Our priorities were constantly changing, as new issues came in, and we couldn’t lock-down the sprint. Things went into and out of the sprint and our burn-down started to look like an electrocardiogram.



              I started to question then whether we should be looking at a continuous workflow and moving over to Kanban. This way we would be able to respond quickly to priority changes, limit our work in progress and work on tasks that would take more than sprint. But Scrum had worked so well for us that I was reluctant to move away from it completely. This is when I hit on ScrumBan.



              What is ScrumBan?



              ScrumBan combines the framework of Scrum with the principles of Kanban. It is more prescriptive than Kanban, which has no roles or meetings, but is more responsive to change than Scrum, where change can only be accommodated at the sprint boundary. ScrumBan retains all the roles and meetings of Scrum but uses the Kanban continuous workflow board. The daily stand-up focusses on flow of tasks across the board and reviews what it would take to move each one forward. The workflow can even include both support and feature work items on the same board, for teams who have to progress tasks in both areas at once. This is a neat solution to dividing teams in half, where those who end up in the support team are generally less impressed than those who remain on the feature team! It allows people to vary the type of task they pick up each time and to share the support load.



              Using the Kanban board allowed us to take advantage of some of the lean principles of limiting work in progress and eliminating blockers. We had a limited number of “Ready” slots available on the board, which the product owner would fill with the top priority items. Should priorities change, or new requests come in, these could be swapped in and swapped out as needed. Ready to progress items were ordered in priority and the team was asked to try to progress the top items first, wherever possible. This was a real exercise in team empowerment and collaboration, and people worked hard to pick up priority items first, rather than those which just looked the nicest! As the Scrum Master, my role remained to facilitate this process and assist to eliminate the blockers that arose.



              ScrumBan activities



              We kept many of the Scrum ceremonies in place, relatively unchanged. The daily stand-up reviewed the progress on the board and allowed individuals to exchange information and offer assistance, even though they weren’t interdependent from working on shared user stories. The stand-up also allowed the opportunity to review our work-in-progress so ensure that individuals weren’t progressing too many tasks in parallel and that nothing was blocked. We retained a weekly backlog sizing meeting to review the new tasks in the backlog. The sizing exercise was still of value in allowing conversations to be held and shared understanding to be reached on what the tasks entailed, even though we weren’t tracking our velocity as before. The Product Owner maintained a backlog of around 10 items in the to-do list at any time, pulling in more from the backlog as soon as the list ran low. As new, high priority items came in, the Product Owner would add these to the top of the to-do list, removing lower priority items back onto the backlog, as necessary. The Product Owner was also always on hand to answer questions about the requirements around the issues that were being addressed and the test coverage necessary to extend our regression suite.  In our case, we didn’t hold a sprint review-type meeting, because the increments were limited to bug fixes. However, I see no reason why there shouldn’t be value in this type of meeting, for sharing the solutions that had been implemented. And, of course, retrospectives were as valuable as ever in reviewing our process and making improvements as the team felt necessary.



              Final thoughts



              The advantage of moving from Scrum to Scrumban, rather than pure Kanban, is the retention of much of the Scrum framework. For a team that needs to move from feature work, to support & bug fixing and back again, this provides a less onerous transition as many of the meetings and the general heartbeat of the team remain unchanged. Further, even for teams who only ever do support, I still see a great deal of value in having the Scrum roles and ceremonies in place as I believe that these add a lot of value which could be missed in a pure Kanban environment.
              by Christine Thompson



              One of the biggest bones of contention that I seem to have had with my various Scrum teams is around sizing and estimating. There seems to be a level of confusion about why to size, how to size, what units to use etc. etc. Whilst there are guidelines out there (for example, see “Agile Estimating and Planning” by Mike Cohn) there is, of course, no right and wrong way to do this and teams must settle on the solution that works for them. But let’s at least review what those guidelines are, as a starting point.



              Sizing User Stories



              User Stories are generally estimated at a high-level, in story points. They are sized relative to each other, rather than in absolute terms. The size of the story, in story points, is a function of its complexity to implement, the effort involved and any risk associated with it. One neat example, given by an old colleague of mine, was for a user story which required the operator to hit the X key once, on the keyboard. Of course this would be low complexity and low effort but if the story increased to hitting the X key one million times, then the complexity is still the same (it’s still a simple task) but now the effort involved in significantly increased and therefore the size of the story is increased too. So both of these factors influence the relative sizing of the story, along with any risks or unknowns that it contains.



              Why size the story?



              I would suggest two reasons for this. The purpose of the estimate is to track velocity so that we can predict when features will be completed. If we know how many story points we can complete in a sprint, and we know how many story points remain on the backlog, we can forecast when features can be delivered. Another key purpose for sizing has to be around the conversation that this draws out of the team. For the individuals to agree on a size, they have to reach a shared understanding of what’s required in the story and they have to be able to agree the size they assign. The discussion it takes to get the individuals to reach consensus is of great value in ensuring a thorough and agreed understanding of the work. Even if we threw the estimate away at the end of the sizing there would still have been value in the exercise.



              Sizing Tasks



              Once we have a user story of the right size (generally 8-13 points, depending on your own ‘value’ of a story point), we will often break this down into individual tasks. This allows the team to understand the individual pieces of work that will be performed to implement the story and to be able to parallelise the work with two or more people. So what about the sizing of these tasks? Tasks are generally sized in ideal time. They are low-level and small enough to know roughly how long we will spend on them. The purpose of sizing the tasks is to allow us to burn-down work during the sprint, so that we can follow our progress and identify early if we are not on track.



              So if we add up the time taken for the tasks, we can calculate how long it takes to implement a story point, right?



              Wrong! Velocity is an average over time and takes a number of sprints to establish. Some stories of the same story point size will take longer to complete than others of the same size. Velocity takes into account a whole team over a period of time. Tasks relate to one person doing a small amount of work. You can’t equate the two and they serve a separate purpose.



              So, in summary:



              Stories are sized in Story Points which provide a high-level comparison of complexity and are externally visible to the stakeholders.



              Tasks are sized in ideal time which provides a low-level measure of effort and are internally visible to the team, allowing them to track progress within a sprint.



              I’ve worked with teams who cannot cope with the abstract concept of story points and need to work in the real world units of time. They estimate everything in either elapsed or in ideal time. They admit that, if forced to use story points, they will have a conversion factor in their head which will allow them to supply this. These are the teams who may benefit from a better understanding of the concept and abstraction of story points. I’ve also worked with teams who prefer to do everything in story points because they hate the idea of switching between the abstract complexities and the actual time taken. They feel that it makes them equate story points to time, which they want to avoid. This seems a slightly more understandable approach, although not always well supported in Agile project tracking software.



              The final word on this, of course, has to belong to the individual team and they must do what works best for them in order to achieve their needs in terms of planning and tracking their work. If it works for them, then it isn’t broken.

              Filter Blog

              By date: By tag: